From mark@townsley.net  Fri Jul  1 01:02:05 2011
Return-Path: <mark@townsley.net>
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 1E95121F88A5; Fri,  1 Jul 2011 01:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.479
X-Spam-Level: 
X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.119,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 2wUoPGfsy0H5; Fri,  1 Jul 2011 01:02:04 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A138221F88A3; Fri,  1 Jul 2011 01:02:03 -0700 (PDT)
Received: by wyj26 with SMTP id 26so2342021wyj.31 for <multiple recipients>; Fri, 01 Jul 2011 01:02:02 -0700 (PDT)
Received: by 10.216.229.220 with SMTP id h70mr874611weq.1.1309507322743; Fri, 01 Jul 2011 01:02:02 -0700 (PDT)
Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fu18sm2164925wbb.10.2011.07.01.01.02.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 01:02:01 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-1-487637714
From: Mark Townsley <mark@townsley.net>
In-Reply-To: <4E0D0281.3020608@raszuk.net>
Date: Fri, 1 Jul 2011 10:01:59 +0200
Message-Id: <E8C8737F-7B2F-492A-B821-8A8FCBC96FE5@townsley.net>
References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar>	<alpine.DEB.2.00.1106300707370.19581@uplift.swm.pp.se>	<4E0C1CF8.7090601@gont.com.ar>	<alpine.DEB.2.00.1106300923280.19581@uplift.swm.pp.se>	<558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net>	<0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> <4E0D0281.3020608@raszuk.net>
To: robert@raszuk.net
X-Mailer: Apple Mail (2.1084)
Cc: fun@ietf.org, homegate@ietf.org
Subject: Re: [homegate] [fun]  HOMENET working group proposal
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: Fri, 01 Jul 2011 08:02:05 -0000

--Apple-Mail-1-487637714
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On Jul 1, 2011, at 1:10 AM, Robert Raszuk wrote:

>=20
> I think this is a great WG proposal and I fully support it's creation.
>=20
> However my ISP is telling me that it has sufficient pool of IPv4 =
addresses for the min next 5-10 years so rolling v6 for residential =
users is completely not that much appealing to him.

My ISP has v6 to a half-million homes and doesn't know how to deal with =
multiple v6 subnets (among other things) aside of manual configuration. =
But let's stay out of "my ISP says" discussions. Clearly, we can come up =
with anecdotes at every extreme. What's important is that, globally, =
IPv6 deployment is finally on the rise and implementations are appearing =
in commercial products targeted at the home.=20

You are probably running IPv6 in your home anyway if you have a Mac, =
linux, or windows machine circa Vista or later. It may be disconnected =
from the Internet (or is possibly connected via some automatic tunnel =
that you may or may not be aware of), but even link-local IPv6 in the =
home is something that should work correctly.=20

>=20
> IETF can build many specs recommending v6 deployments, protocol =
extensions and network architectures. Unfortunately before the day  when =
there is first attractive real content available online _only_ via v6 or =
when there is new killer app which works only over v6 I think the world =
will become more and more fragmented into islands of v4, v4v6 and v6 =
only.
>=20
> The issue is not technical here and IETF will not I am afraid be able =
to fix it.

There are technical issues with deploying IPv6 in the home, and that is =
what homenet is slated to work on.=20

> The issue is purely business driven and till all providers get clear =
message from their users that they must have v6 as they can not google =
anymore, pay their bills, use new fancy holographic movie downloader app =
(just as examples) the migration towards v6 may take not 10 but 50 to =
100 years.

Ah yes, the Killer App - it would all too easy if IPv6 had a visicalc or =
wordstar equivalent to drive sales, wouldn't it?=20

http://en.wikipedia.org/wiki/Killer_application

That discussion is not really within the scope of this WG though.

- Mark

>=20
> Cheers,
> R.
> _______________________________________________
> fun mailing list
> fun@ietf.org
> https://www.ietf.org/mailman/listinfo/fun


--Apple-Mail-1-487637714
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Jul 1, 2011, at 1:10 AM, Robert Raszuk =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div><br>I think this is a great WG proposal and I fully =
support it's creation.<br><br>However my ISP is telling me that it has =
sufficient pool of IPv4 addresses for the min next 5-10 years so rolling =
v6 for residential users is completely not that much appealing to =
him.<br></div></blockquote><div><br></div><div>My ISP has v6 to a =
half-million homes and doesn't know how to deal with multiple v6 subnets =
(among other things) aside of manual configuration.&nbsp;But let's stay =
out of "my ISP says" discussions. Clearly, we can come up with anecdotes =
at every extreme. What's important is that, globally, IPv6 deployment is =
finally on the rise and implementations are appearing in commercial =
products targeted at the home.&nbsp;</div><div><br></div><div>You are =
probably running IPv6 in your home anyway if you have a Mac, linux, or =
windows machine circa Vista or later. It may be disconnected from the =
Internet (or is possibly connected via some automatic tunnel that you =
may or may not be aware of), but even link-local IPv6 in the home is =
something that should work correctly.&nbsp;</div><br><blockquote =
type=3D"cite"><div><br>IETF can build many specs recommending v6 =
deployments, protocol extensions and network architectures. =
Unfortunately before the day &nbsp;when there is first attractive real =
content available online _only_ via v6 or when there is new killer app =
which works only over v6 I think the world will become more and more =
fragmented into islands of v4, v4v6 and v6 only.<br><br>The issue is not =
technical here and IETF will not I am afraid be able to fix =
it.<br></div></blockquote><div><br></div><div>There are technical issues =
with deploying IPv6 in the home, and that is what homenet is slated to =
work on.&nbsp;</div><br><blockquote type=3D"cite"><div>The issue is =
purely business driven and till all providers get clear message from =
their users that they must have v6 as they can not google anymore, pay =
their bills, use new fancy holographic movie downloader app (just as =
examples) the migration towards v6 may take not 10 but 50 to 100 =
years.</div></blockquote><div><br></div><div>Ah yes, the Killer App - it =
would all too easy if IPv6 had a visicalc or wordstar equivalent to =
drive sales, wouldn't it?&nbsp;</div><div><br></div><div><a =
href=3D"http://en.wikipedia.org/wiki/Killer_application">http://en.wikiped=
ia.org/wiki/Killer_application</a></div><div><br></div><div>That =
discussion is not really within the scope of this WG =
though.</div><div><br></div><div>- Mark</div><br><blockquote =
type=3D"cite"><div><br>Cheers,<br>R.<br>__________________________________=
_____________<br>fun mailing list<br><a =
href=3D"mailto:fun@ietf.org">fun@ietf.org</a><br>https://www.ietf.org/mail=
man/listinfo/fun<br></div></blockquote></div><br></body></html>=

--Apple-Mail-1-487637714--

From mark@townsley.net  Fri Jul  1 01:06:57 2011
Return-Path: <mark@townsley.net>
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 B0B9521F886C; Fri,  1 Jul 2011 01:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.199
X-Spam-Level: 
X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
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 bCiD27R0xQK9; Fri,  1 Jul 2011 01:06:52 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E16D21F884E; Fri,  1 Jul 2011 01:06:51 -0700 (PDT)
Received: by wwe5 with SMTP id 5so2013580wwe.13 for <multiple recipients>; Fri, 01 Jul 2011 01:06:50 -0700 (PDT)
Received: by 10.227.172.13 with SMTP id j13mr2665983wbz.45.1309507610489; Fri, 01 Jul 2011 01:06:50 -0700 (PDT)
Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fu18sm2167622wbb.10.2011.07.01.01.06.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 01:06:49 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Mark Townsley <mark@townsley.net>
In-Reply-To: <E104C094D4487643BB93F43875CBCBCF032BD3CE@XMB-RCD-203.cisco.com>
Date: Fri, 1 Jul 2011 10:06:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C6B9766C-6759-4E6D-8FF7-C8F6C1DFC016@townsley.net>
References: <E104C094D4487643BB93F43875CBCBCF032BD3CE@XMB-RCD-203.cisco.com>
To: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
X-Mailer: Apple Mail (2.1084)
Cc: fun@ietf.org, homegate@ietf.org, jason.weil@twcable.com
Subject: Re: [homegate] [fun] status of the homenet effort
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: Fri, 01 Jul 2011 08:06:57 -0000

On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote:

> I also think that this deals with an important topic and the list of =
items listed on the proposed charter are quite relevant. I'm just not =
entirely clear on the "routing component": are you referring to:
> * A requirement document for Routing in the home?

At least a section within a home architecture document.

> * A recommendation for a specific routing protocol ?

> * A framework before the specification of a new routing protocol ?

The charter says:

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

- Mark


> I'm clearly not expressing an opinion, just a question.
> Thanks.
> JP.
>=20
> JP Vasseur
> Cisco Fellow
>=20
> Sent from Blackberry
>=20
> ----- Original Message -----
> From: Mark Townsley [mailto:mark@townsley.net]
> Sent: Thursday, June 30, 2011 11:36 AM
> To: Weil, Jason <jason.weil@twcable.com>
> Cc: fun@ietf.org <fun@ietf.org>; homegate@ietf.org <homegate@ietf.org>
> Subject: Re: [fun] status of the homenet effort
>=20
>=20
> Thank you for the feedback, keep it coming.
>=20
> On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote:
>=20
>> Mark, Raplh, Jari, et all,
>>=20
>> I really appreciate the change in charter and direction for this =
proposed
>> WG and the interest to keep it going. I believe it sets a path that =
is
>> scoped narrow enough to provide a workplace for achievable results.
>>=20
>> As a provider working on writing, testing and implementing IPv6 CPE, =
I can
>> relate firsthand that getting basic IPv6 functionality working in the =
home
>> network is no simple feat and is still a work in progress. Don't get =
me
>> wrong, basic functionality is there just not baked. What seems very
>> straightforward in theory typically fails in a multitude of corner =
cases
>> ie reality. And just to clarify I am referring to a single /64 subnet
>> topology with no routing.
>>=20
>> If we can stay focussed on solving just the basics for the five areas
>> included, I believe it will be helpful. The other recommendation =
would be
>> to work as expeditiously as possible. Providers in the process of
>> deploying IPv6 now are already deep into this analysis and =
development
>> with their vendors. If we wait too long then these topics will be =
solved
>> with interoperability a possible casualty.
>>=20
>> FWIW, I would also add that the five topics in the charter are also =
listed
>> in order
>> Of priority at least for me.
>>=20
>>=20
>> Thanks,
>>=20
>> Jason
>>=20
>>=20
>> On 6/29/11 5:46 AM, "Mark Townsley" <mark@townsley.net> wrote:
>>=20
>>>=20
>>> All,
>>>=20
>>> Apologies for double-posting if there are folks that are subscribed =
to
>>> homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone =
will
>>> finally create homenet@ietf.org and consolidate the membership
>>> accordingly.
>>>=20
>>> In the charter proposal below, I think you will see a lot of =
similarity
>>> with the consensus we achieved on the homegate list last year. Jari =
has
>>> taken that, feedback from the IESG, IAB, members of the =
IP-Directorate,
>>> v6ops chairs, etc. and shaped it towards something more focused on =
the
>>> Internet (and Routing) area, as well as IPv6. I believe he and Ralph =
both
>>> have a great deal of confidence that this is something that is very
>>> important to the industry, and that the IETF has a critical role to =
play.
>>>=20
>>> So, make no mistake, whether we end up as a WG or a BoF between now =
and
>>> Quebec, "we're back" - please send comments, and make your travel or
>>> remote-attendance plans accordingly if you want to participate.
>>>=20
>>> Jari has asked me to co-chair the session in Quebec. As such, I'd =
like to
>>> take requests for presentation time now. Jari and I will likely =
begin the
>>> session with a scoping overview, as well as a first cut at an
>>> architecture framework, but there should be some time for a few =
other
>>> items. When submitting your request, please identify which of the 5 =
areas
>>> below you think your work applies to as well as the internet-draft, =
of
>>> course.
>>>=20
>>> Thanks, and see you on the list and in Quebec.
>>>=20
>>> - Mark
>>>=20
>>>=20
>>> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote:
>>>=20
>>>> I wanted to provide an update of the situation with this working =
group
>>>> proposal.
>>>>=20
>>>> HOMENET is a new working group proposal, a variation of the
>>>> HOMEGATE/HOMENET theme that we discussed last year, but this time
>>>> looking at it from a different angle. The old effort was mostly =
focused
>>>> about what home gateways should do: forwarding, transport, and DNS
>>>> proxying issues. The new effort is about home networks themselves, =
in
>>>> particular what kind of network architecture and configuration is
>>>> necessary to support IPv6-based home networks. We view IPv4-based =
home
>>>> networks as "done" at this time (or perhaps as "cannot be changed
>>>> anyway").
>>>>=20
>>>> I have been discussing this effort in the background for the last
>>>> couple of month with Mark Townsley and others, and more publicly =
since
>>>> early June. The proposal has been brought to the IESG, IAB and some
>>>> directorates for discussion, and we've been going back and forth =
whether
>>>> this is ready to become a working group or needs to be run as a BOF =
in
>>>> Quebec City. The current plan is that the working group proposal =
goes to
>>>> IETF-wide review this week, and if the feedback from the community, =
IAB,
>>>> and the IESG is positive, we will create the working group just in =
time
>>>> for the IETF. Otherwise, the slot reserved in the agenda for the =
meeting
>>>> will be used to run the proposal as a BOF.
>>>>=20
>>>> In any case, I would like to solicit discussion on this topic, and
>>>> perhaps some early drafts as well. Please comment on the charter at
>>>> least.
>>>>=20
>>>> Note that the new proposal was called FUN at the time that we =
created
>>>> the list. It has now been renamed back to HOMENET to be more
>>>> descriptive. The list will be renamed soon as well (current =
subscribers
>>>> will stay).
>>>>=20
>>>> This is the most recent version of the charter we should discuss:
>>>>=20
>>>> Home Networks (homenet)
>>>> -----------------------------------
>>>>=20
>>>> Current Status: Proposed
>>>> Last Edit: Wednesday, June 29th, 2011
>>>>=20
>>>> Chairs:
>>>> TBD
>>>>=20
>>>> Internet Area Directors:
>>>> Ralph Droms <rdroms.ietf@gmail.com>
>>>> Jari Arkko <jari.arkko@piuha.net>
>>>>=20
>>>> Internet Area Advisor:
>>>> Jari Arkko <jari.arkko@piuha.net>
>>>>=20
>>>> Routing Area Technical Advisor:
>>>> TBD
>>>>=20
>>>> Security Area Technical Advisor:
>>>> TBD
>>>>=20
>>>> 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
>>>>=20
>>>> Description of Working Group:
>>>>=20
>>>> This working group focuses on the evolving networking technology
>>>> within and among relatively small =B3residential home=B2 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:
>>>>=20
>>>> 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. Different segments may be associated with
>>>> subnets that have different routing and security policies.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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. 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:
>>>>=20
>>>> o prefix configuration for routers
>>>> o managing routing
>>>> o name resolution
>>>> o service discovery
>>>> o network security
>>>>=20
>>>> 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. 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 one 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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 liase 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.
>>>>=20
>>>> Milestones:
>>>>=20
>>>> 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
>>>>=20
>>>> _______________________________________________
>>>> fun mailing list
>>>> fun@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/fun
>>>=20
>>> _______________________________________________
>>> fun mailing list
>>> fun@ietf.org
>>> https://www.ietf.org/mailman/listinfo/fun
>>=20
>>=20
>> This E-mail and any of its attachments may contain Time Warner Cable =
proprietary information, which is privileged, confidential, or subject =
to copyright belonging to Time Warner Cable. This E-mail is intended =
solely for the use of the individual or entity to which it is addressed. =
If you are not the intended recipient of this E-mail, you are hereby =
notified that any dissemination, distribution, copying, or action taken =
in relation to the contents of and attachments to this E-mail is =
strictly prohibited and may be unlawful. If you have received this =
E-mail in error, please notify the sender immediately and permanently =
delete the original and any copy of this E-mail and any printout.
>=20
> _______________________________________________
> fun mailing list
> fun@ietf.org
> https://www.ietf.org/mailman/listinfo/fun


From jvasseur@cisco.com  Thu Jun 30 22:27:28 2011
Return-Path: <jvasseur@cisco.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 D027121F869B; Thu, 30 Jun 2011 22:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level: 
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
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 LLuJtkiuTc66; Thu, 30 Jun 2011 22:27:25 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id F17EC21F8696; Thu, 30 Jun 2011 22:27:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=15713; q=dns/txt; s=iport; t=1309498044; x=1310707644; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:from:to:cc; bh=uaUm9vbvJnqfI0fKoFk0oPAkuW0/YEU+2x93kO1dSII=; b=YH8QhwaVL4cad8Q+ZYYHus3ulPyxw1HVCFzVmklHwqTuj7lk62szEnfv VLZglQJmepVMGlCDFtoCFKrIL37PRKBrXnLrFM6bWFoXL34ZiIMbhOrfc pZ//T4Eu375C3/1zWW2u3816rYT/ZokvLmlUoB9Zde8phApFBOM5j1bR3 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvIAAI9ZDU6tJXG//2dsb2JhbABEDpgrjzJ3iHmiJJ1xgx8TgwAEhz6PcYRHhwg
X-IronPort-AV: E=Sophos;i="4.65,456,1304294400"; d="scan'208";a="351128749"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-3.cisco.com with ESMTP; 01 Jul 2011 05:27:22 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p615RM2Q016713;  Fri, 1 Jul 2011 05:27:22 GMT
Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 1 Jul 2011 00:27:22 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 1 Jul 2011 00:27:21 -0500
Message-ID: <E104C094D4487643BB93F43875CBCBCF032BD3CE@XMB-RCD-203.cisco.com>
In-Reply-To: <7D900BF0-EA18-4ADA-A447-A9D3A717B61C@townsley.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [fun] status of the homenet effort
Thread-Index: Acw3RKfd7kxyV7l1RY669+qj09MH3gAauVbb
From: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
To: <mark@townsley.net>, <jason.weil@twcable.com>
X-OriginalArrivalTime: 01 Jul 2011 05:27:22.0314 (UTC) FILETIME=[8DB4C2A0:01CC37AF]
X-Mailman-Approved-At: Fri, 01 Jul 2011 01:21:00 -0700
Cc: fun@ietf.org, homegate@ietf.org
Subject: Re: [homegate] [fun] status of the homenet effort
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: Fri, 01 Jul 2011 05:27:28 -0000

I also think that this deals with an important topic and the list of =
items listed on the proposed charter are quite relevant. I'm just not =
entirely clear on the "routing component": are you referring to:
* A requirement document for Routing in the home?
* A recommendation for a specific routing protocol ?
* A framework before the specification of a new routing protocol ?
I'm clearly not expressing an opinion, just a question.
Thanks.
JP.

JP Vasseur
Cisco Fellow

Sent from Blackberry

----- Original Message -----
From: Mark Townsley [mailto:mark@townsley.net]
Sent: Thursday, June 30, 2011 11:36 AM
To: Weil, Jason <jason.weil@twcable.com>
Cc: fun@ietf.org <fun@ietf.org>; homegate@ietf.org <homegate@ietf.org>
Subject: Re: [fun] status of the homenet effort


Thank you for the feedback, keep it coming.

On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote:

> Mark, Raplh, Jari, et all,
>=20
> I really appreciate the change in charter and direction for this =
proposed
> WG and the interest to keep it going. I believe it sets a path that is
> scoped narrow enough to provide a workplace for achievable results.
>=20
> As a provider working on writing, testing and implementing IPv6 CPE, I =
can
> relate firsthand that getting basic IPv6 functionality working in the =
home
> network is no simple feat and is still a work in progress. Don't get =
me
> wrong, basic functionality is there just not baked. What seems very
> straightforward in theory typically fails in a multitude of corner =
cases
> ie reality. And just to clarify I am referring to a single /64 subnet
> topology with no routing.
>=20
> If we can stay focussed on solving just the basics for the five areas
> included, I believe it will be helpful. The other recommendation would =
be
> to work as expeditiously as possible. Providers in the process of
> deploying IPv6 now are already deep into this analysis and development
> with their vendors. If we wait too long then these topics will be =
solved
> with interoperability a possible casualty.
>=20
> FWIW, I would also add that the five topics in the charter are also =
listed
> in order
> Of priority at least for me.
>=20
>=20
> Thanks,
>=20
> Jason
>=20
>=20
> On 6/29/11 5:46 AM, "Mark Townsley" <mark@townsley.net> wrote:
>=20
>>=20
>> All,
>>=20
>> Apologies for double-posting if there are folks that are subscribed =
to
>> homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone will
>> finally create homenet@ietf.org and consolidate the membership
>> accordingly.
>>=20
>> In the charter proposal below, I think you will see a lot of =
similarity
>> with the consensus we achieved on the homegate list last year. Jari =
has
>> taken that, feedback from the IESG, IAB, members of the =
IP-Directorate,
>> v6ops chairs, etc. and shaped it towards something more focused on =
the
>> Internet (and Routing) area, as well as IPv6. I believe he and Ralph =
both
>> have a great deal of confidence that this is something that is very
>> important to the industry, and that the IETF has a critical role to =
play.
>>=20
>> So, make no mistake, whether we end up as a WG or a BoF between now =
and
>> Quebec, "we're back" - please send comments, and make your travel or
>> remote-attendance plans accordingly if you want to participate.
>>=20
>> Jari has asked me to co-chair the session in Quebec. As such, I'd =
like to
>> take requests for presentation time now. Jari and I will likely begin =
the
>> session with a scoping overview, as well as a first cut at an
>> architecture framework, but there should be some time for a few other
>> items. When submitting your request, please identify which of the 5 =
areas
>> below you think your work applies to as well as the internet-draft, =
of
>> course.
>>=20
>> Thanks, and see you on the list and in Quebec.
>>=20
>> - Mark
>>=20
>>=20
>> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote:
>>=20
>>> I wanted to provide an update of the situation with this working =
group
>>> proposal.
>>>=20
>>> HOMENET is a new working group proposal, a variation of the
>>> HOMEGATE/HOMENET theme that we discussed last year, but this time
>>> looking at it from a different angle. The old effort was mostly =
focused
>>> about what home gateways should do: forwarding, transport, and DNS
>>> proxying issues. The new effort is about home networks themselves, =
in
>>> particular what kind of network architecture and configuration is
>>> necessary to support IPv6-based home networks. We view IPv4-based =
home
>>> networks as "done" at this time (or perhaps as "cannot be changed
>>> anyway").
>>>=20
>>> I have been discussing this effort in the background for the last
>>> couple of month with Mark Townsley and others, and more publicly =
since
>>> early June. The proposal has been brought to the IESG, IAB and some
>>> directorates for discussion, and we've been going back and forth =
whether
>>> this is ready to become a working group or needs to be run as a BOF =
in
>>> Quebec City. The current plan is that the working group proposal =
goes to
>>> IETF-wide review this week, and if the feedback from the community, =
IAB,
>>> and the IESG is positive, we will create the working group just in =
time
>>> for the IETF. Otherwise, the slot reserved in the agenda for the =
meeting
>>> will be used to run the proposal as a BOF.
>>>=20
>>> In any case, I would like to solicit discussion on this topic, and
>>> perhaps some early drafts as well. Please comment on the charter at
>>> least.
>>>=20
>>> Note that the new proposal was called FUN at the time that we =
created
>>> the list. It has now been renamed back to HOMENET to be more
>>> descriptive. The list will be renamed soon as well (current =
subscribers
>>> will stay).
>>>=20
>>> This is the most recent version of the charter we should discuss:
>>>=20
>>> Home Networks (homenet)
>>> -----------------------------------
>>>=20
>>> Current Status: Proposed
>>> Last Edit: Wednesday, June 29th, 2011
>>>=20
>>> Chairs:
>>> TBD
>>>=20
>>> Internet Area Directors:
>>> Ralph Droms <rdroms.ietf@gmail.com>
>>> Jari Arkko <jari.arkko@piuha.net>
>>>=20
>>> Internet Area Advisor:
>>> Jari Arkko <jari.arkko@piuha.net>
>>>=20
>>> Routing Area Technical Advisor:
>>> TBD
>>>=20
>>> Security Area Technical Advisor:
>>> TBD
>>>=20
>>> 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
>>>=20
>>> Description of Working Group:
>>>=20
>>> This working group focuses on the evolving networking technology
>>> within and among relatively small =B3residential home=B2 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:
>>>=20
>>> 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. Different segments may be associated with
>>> subnets that have different routing and security policies.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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. 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:
>>>=20
>>> o prefix configuration for routers
>>> o managing routing
>>> o name resolution
>>> o service discovery
>>> o network security
>>>=20
>>> 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. 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 one 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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 liase 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.
>>>=20
>>> Milestones:
>>>=20
>>> 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
>>>=20
>>> _______________________________________________
>>> fun mailing list
>>> fun@ietf.org
>>> https://www.ietf.org/mailman/listinfo/fun
>>=20
>> _______________________________________________
>> fun mailing list
>> fun@ietf.org
>> https://www.ietf.org/mailman/listinfo/fun
>=20
>=20
> This E-mail and any of its attachments may contain Time Warner Cable =
proprietary information, which is privileged, confidential, or subject =
to copyright belonging to Time Warner Cable. This E-mail is intended =
solely for the use of the individual or entity to which it is addressed. =
If you are not the intended recipient of this E-mail, you are hereby =
notified that any dissemination, distribution, copying, or action taken =
in relation to the contents of and attachments to this E-mail is =
strictly prohibited and may be unlawful. If you have received this =
E-mail in error, please notify the sender immediately and permanently =
delete the original and any copy of this E-mail and any printout.

_______________________________________________
fun mailing list
fun@ietf.org
https://www.ietf.org/mailman/listinfo/fun

From jvasseur@cisco.com  Thu Jun 30 22:30:19 2011
Return-Path: <jvasseur@cisco.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 4215B21F869B; Thu, 30 Jun 2011 22:30:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 WunDwdCTiGS3; Thu, 30 Jun 2011 22:30:15 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 821B821F86BD; Thu, 30 Jun 2011 22:30:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=1903; q=dns/txt; s=iport; t=1309498215; x=1310707815; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:from:to:cc; bh=+Ltjwy5EJJwOl/+/MsYUAqAvJQKr07MYx1z2X1K3YIs=; b=OPq3j1dfSq9dNWtgpMoC5wcSUFY/59NzjbQNhSDeZIi+gTpQQ0rS/60J An7wVsEBPX+i6HrL0/3qt97nIHTdob9ke93ZrIjBuOIZwZMmu1McK9j+I wgLqmnFcJDvVwXRHJXLKU1g8Dmd5mWtM5j+93W66w0X21vxY2DjtntBXF I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvIAAKRaDU6tJV2a/2dsb2JhbABSmCuPMneIeaIlnXKGMgSHPo9xi08
X-IronPort-AV: E=Sophos;i="4.65,456,1304294400"; d="scan'208";a="725212169"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by sj-iport-6.cisco.com with ESMTP; 01 Jul 2011 05:30:14 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p615UEZJ019423;  Fri, 1 Jul 2011 05:30:14 GMT
Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 1 Jul 2011 00:30:14 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 1 Jul 2011 00:30:14 -0500
Message-ID: <E104C094D4487643BB93F43875CBCBCF032BD3CF@XMB-RCD-203.cisco.com>
In-Reply-To: <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [fun] [homegate] HOMENET working group proposal
Thread-Index: Acw3RGDhWzyvVlXSTKCZLwtsLh7yEgAa5NF6
From: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
To: <mark@townsley.net>, <moore@network-heretics.com>
X-OriginalArrivalTime: 01 Jul 2011 05:30:14.0580 (UTC) FILETIME=[F4627740:01CC37AF]
X-Mailman-Approved-At: Fri, 01 Jul 2011 01:22:55 -0700
Cc: ietf@ietf.org, homegate@ietf.org, fun@ietf.org
Subject: Re: [homegate] [fun]  HOMENET working group proposal
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: Fri, 01 Jul 2011 05:30:19 -0000

I'd like to second the relaxation of "wherever possible", which may lead =
to a suboptimal solution for several components.

JP Vasseur
Cisco Fellow

Sent from Blackberry

----- Original Message -----
From: Mark Townsley [mailto:mark@townsley.net]
Sent: Thursday, June 30, 2011 11:33 AM
To: Keith Moore <moore@network-heretics.com>
Cc: IETF Discussion <ietf@ietf.org>; fun@ietf.org <fun@ietf.org>; =
homegate@ietf.org <homegate@ietf.org>
Subject: Re: [fun] [homegate] HOMENET working group proposal



On Jun 30, 2011, at 5:46 PM, Keith Moore wrote:

>=20
> On Jun 30, 2011, at 5:57 AM, Mark Townsley wrote:
>=20
>>=20
>> I think the consensus we had in the past BoFs and discussion in and =
around this topic can be summed up as stating that homenet deliverables =
will:
>>=20
>> - coexist with (existing) IPv4 protocols, devices, applications, etc.
>> - operate in a (future) IPv6-only home network in the absence of IPv4
>> - be IP-agnostic whenever possible
>=20
> I'd like for this group to relax the "wherever possible" bit, so as to =
not preclude solutions where IPv6 can do a better job than IPv4.

Yes, and I think that IPv6 should naturally do a better job than IPv4 in =
the cases where it can.=20

My original mail had this restatement of the above, which I think gets =
closer to what you want:

>> However, when we can define something that is needed for IPv6 in a =
way that is also useful for IPv4 without making significant concessions, =
we should go ahead and do so.


- Mark

>=20
> IPv4 is a dinosaur gasping for its last breaths.
>=20
> Keith
>=20
>=20
> _______________________________________________
> homegate mailing list
> homegate@ietf.org
> https://www.ietf.org/mailman/listinfo/homegate

_______________________________________________
fun mailing list
fun@ietf.org
https://www.ietf.org/mailman/listinfo/fun

From mark@townsley.net  Fri Jul  1 01:53:44 2011
Return-Path: <mark@townsley.net>
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 3A9F721F87AA; Fri,  1 Jul 2011 01:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.47
X-Spam-Level: 
X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.129,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 tM0+oPmkZUNK; Fri,  1 Jul 2011 01:53:43 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0965C21F86F4; Fri,  1 Jul 2011 01:53:42 -0700 (PDT)
Received: by wyj26 with SMTP id 26so2373562wyj.31 for <multiple recipients>; Fri, 01 Jul 2011 01:53:41 -0700 (PDT)
Received: by 10.216.132.214 with SMTP id o64mr2564631wei.75.1309510421783; Fri, 01 Jul 2011 01:53:41 -0700 (PDT)
Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id u38sm700625weq.37.2011.07.01.01.53.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 01:53:39 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley <mark@townsley.net>
In-Reply-To: <DC5C1553-38E9-4853-9AEA-61FC34FC5EC8@network-heretics.com>
Date: Fri, 1 Jul 2011 10:53:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B6FEF9D-430B-4C56-BB21-40C5ED888B51@townsley.net>
References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <alpine.DEB.2.00.1106300707370.19581@uplift.swm.pp.se> <4E0C1CF8.7090601@gont.com.ar> <alpine.DEB.2.00.1106300923280.19581@uplift.swm.pp.se> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> <DC5C1553-38E9-4853-9AEA-61FC34FC5EC8@network-heretics.com>
To: Keith Moore <moore@network-heretics.com>
X-Mailer: Apple Mail (2.1084)
Cc: IETF Discussion <ietf@ietf.org>, homegate@ietf.org, fun@ietf.org
Subject: Re: [homegate] HOMENET working group proposal
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: Fri, 01 Jul 2011 08:53:44 -0000

On Jun 30, 2011, at 6:36 PM, Keith Moore wrote:

> On Jun 30, 2011, at 12:33 PM, Mark Townsley wrote:
>>>>=20
>>>> I think the consensus we had in the past BoFs and discussion in and =
around this topic can be summed up as stating that homenet deliverables =
will:
>>>>=20
>>>> - coexist with (existing) IPv4 protocols, devices, applications, =
etc.
>>>> - operate in a (future) IPv6-only home network in the absence of =
IPv4
>>>> - be IP-agnostic whenever possible
>>>=20
>>> I'd like for this group to relax the "wherever possible" bit, so as =
to not preclude solutions where IPv6 can do a better job than IPv4.
>>=20
>> Yes, and I think that IPv6 should naturally do a better job than IPv4 =
in the cases where it can.=20
>>=20
>> My original mail had this restatement of the above, which I think =
gets closer to what you want:
>>=20
>>>> However, when we can define something that is needed for IPv6 in a =
way that is also useful for IPv4 without making significant concessions, =
we should go ahead and do so.
>=20
> when the group can define something that is useful in IPv6, it =
shouldn't matter whether it's also useful for IPv4.

The idea is not to go out of our way for IPv4, but if the topic is IP =
agnostic anyway, so be it. To be clear, there is no *requirement* to =
support IPv4 here. However, there is no requirement to avoid IPv4 *if* =
it doesn't cause significant concession in the IPv6 design either.

This cuts both ways, if there is something that is working well in IPv4 =
that we need to carry over to IPv6 with simple extensions, we'll do that =
and capitalizing on that running-code should be considered a good thing. =
We don't want to invent new v6 protocols from scratch that don't work =
with IPv4 when there is no need. For example (and I think this is hinted =
at in the charter), we might use naming and service discovery that =
already exists for IPv4, adapted the the v6 homenet. This doesn't mean =
we need to re-invent a v6-only naming system from scratch - i'd much =
rather use one that is there, which very well may support v4 and v6.=20

>=20
> please don't constrain home networks to work only within the confines =
of IPv4 brain damage.

What I think I am saying here is that we will do our best to perform as =
if our brains are not damaged, and equally try to avoid damaging our =
brains in the process.

- Mark

>=20
> Keith
>=20
> _______________________________________________
> homegate mailing list
> homegate@ietf.org
> https://www.ietf.org/mailman/listinfo/homegate


From jason.weil@twcable.com  Fri Jul  1 06:33:42 2011
Return-Path: <jason.weil@twcable.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 03AF811E80FD; Fri,  1 Jul 2011 06:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.864
X-Spam-Level: 
X-Spam-Status: No, score=0.864 tagged_above=-999 required=5 tests=[AWL=-1.026,  BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368,  J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753]
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 iggWFojARrgh; Fri,  1 Jul 2011 06:33:40 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id F3EB911E8127; Fri,  1 Jul 2011 06:32:27 -0700 (PDT)
X-SENDER-IP: 10.136.163.10
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.65,458,1304308800"; d="scan'208";a="244804822"
Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 01 Jul 2011 09:31:04 -0400
Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Fri, 1 Jul 2011 09:32:12 -0400
From: "Weil, Jason" <jason.weil@twcable.com>
To: Mark Townsley <mark@townsley.net>, "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
Date: Fri, 1 Jul 2011 09:32:11 -0400
Thread-Topic: [fun] status of the homenet effort
Thread-Index: Acw380h/wVPhDWgST5W2OIltGtCygA==
Message-ID: <CA3341C2.4C55%jason.weil@twcable.com>
In-Reply-To: <C6B9766C-6759-4E6D-8FF7-C8F6C1DFC016@townsley.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.0.0.100825
acceptlanguage: en-US
Content-Type: text/plain; charset="euc-kr"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 01 Jul 2011 07:02:54 -0700
Cc: "fun@ietf.org" <fun@ietf.org>, "homegate@ietf.org" <homegate@ietf.org>
Subject: Re: [homegate] [fun] status of the homenet effort
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: Fri, 01 Jul 2011 13:33:42 -0000

DQoNCk9uIDcvMS8xMSA0OjA2IEFNLCAiTWFyayBUb3duc2xleSIgPG1hcmtAdG93bnNsZXkubmV0
PiB3cm90ZToNCg0KPg0KPk9uIEp1bCAxLCAyMDExLCBhdCA3OjI3IEFNLCBKUCBWYXNzZXVyIChq
dmFzc2V1cikgd3JvdGU6DQo+DQo+PiBJIGFsc28gdGhpbmsgdGhhdCB0aGlzIGRlYWxzIHdpdGgg
YW4gaW1wb3J0YW50IHRvcGljIGFuZCB0aGUgbGlzdCBvZg0KPj5pdGVtcyBsaXN0ZWQgb24gdGhl
IHByb3Bvc2VkIGNoYXJ0ZXIgYXJlIHF1aXRlIHJlbGV2YW50LiBJJ20ganVzdCBub3QNCj4+ZW50
aXJlbHkgY2xlYXIgb24gdGhlICJyb3V0aW5nIGNvbXBvbmVudCI6IGFyZSB5b3UgcmVmZXJyaW5n
IHRvOg0KPj4gKiBBIHJlcXVpcmVtZW50IGRvY3VtZW50IGZvciBSb3V0aW5nIGluIHRoZSBob21l
Pw0KPg0KPkF0IGxlYXN0IGEgc2VjdGlvbiB3aXRoaW4gYSBob21lIGFyY2hpdGVjdHVyZSBkb2N1
bWVudC4NCj4NCj4+ICogQSByZWNvbW1lbmRhdGlvbiBmb3IgYSBzcGVjaWZpYyByb3V0aW5nIHBy
b3RvY29sID8NCg0KW0pXXSBJIHNlZSBhIGd1aWRlbGluZXMvYW5hbHlzaXMgZm9yIGxpbmstc3Rh
dGUgdnMuIGRpc3RhbmNlLXZlY3Rvcg0Kcm91dGluZyBwcm90b2NvbHMgaW4gYSBtdWx0aS1zZWdt
ZW50IGhvbWUgbmV0d29yayBhcyBiZWluZyB1c2VmdWwuDQoNCj4NCj4+ICogQSBmcmFtZXdvcmsg
YmVmb3JlIHRoZSBzcGVjaWZpY2F0aW9uIG9mIGEgbmV3IHJvdXRpbmcgcHJvdG9jb2wgPw0KDQpb
SlddIEEgZnJhbWV3b3JrIG9yIGp1c3RpZmljYXRpb24gc3RhdGVtZW50IGZvciBhIG5ldyBsaWdo
dHdlaWdodCByb3V0aW5nDQpwcm90b2NvbCB3b3VsZCBiZSB1c2VmdWwgYXMgd2VsbC4gQSBzb3Vy
Y2UvZGVzdCBhd2FyZSBwcm90b2NvbCBoYXMgYmVlbg0KcHJvcG9zZWQgYXMgYSBwb3NzaWJsZSBz
b2x1dGlvbiBmb3IgdGhlIG11bHRpLWhvbWVkIGhvbWUgbmV0d29yayBmb3INCmV4YW1wbGUuDQoN
Cj4NCj5UaGUgY2hhcnRlciBzYXlzOg0KPg0KPiJGb3IgYXV0b21hdGljIHJvdXRpbmcsIGl0IGlz
IGV4cGVjdGVkIHRoYXQgZXhpc3RpbmcNCj5yb3V0aW5nIHByb3RvY29scyBjYW4gYmUgdXNlZCBh
cyBpcywgaG93ZXZlciwgYSBuZXcgbWVjaGFuaXNtIG1heSBiZQ0KPm5lZWRlZCBpbiBvcmRlciB0
byB0dXJuIGEgc2VsZWN0ZWQgcHJvdG9jb2wgb24gYnkgZGVmYXVsdC4iDQo+DQo+LSBNYXJrDQo+
DQo+DQo+PiBJJ20gY2xlYXJseSBub3QgZXhwcmVzc2luZyBhbiBvcGluaW9uLCBqdXN0IGEgcXVl
c3Rpb24uDQo+PiBUaGFua3MuDQo+PiBKUC4NCj4+DQo+PiBKUCBWYXNzZXVyDQo+PiBDaXNjbyBG
ZWxsb3cNCj4+DQo+PiBTZW50IGZyb20gQmxhY2tiZXJyeQ0KPj4NCj4+IC0tLS0tIE9yaWdpbmFs
IE1lc3NhZ2UgLS0tLS0NCj4+IEZyb206IE1hcmsgVG93bnNsZXkgW21haWx0bzptYXJrQHRvd25z
bGV5Lm5ldF0NCj4+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDMwLCAyMDExIDExOjM2IEFNDQo+PiBU
bzogV2VpbCwgSmFzb24gPGphc29uLndlaWxAdHdjYWJsZS5jb20+DQo+PiBDYzogZnVuQGlldGYu
b3JnIDxmdW5AaWV0Zi5vcmc+OyBob21lZ2F0ZUBpZXRmLm9yZyA8aG9tZWdhdGVAaWV0Zi5vcmc+
DQo+PiBTdWJqZWN0OiBSZTogW2Z1bl0gc3RhdHVzIG9mIHRoZSBob21lbmV0IGVmZm9ydA0KPj4N
Cj4+DQo+PiBUaGFuayB5b3UgZm9yIHRoZSBmZWVkYmFjaywga2VlcCBpdCBjb21pbmcuDQo+Pg0K
Pj4gT24gSnVuIDMwLCAyMDExLCBhdCA0OjE0IFBNLCBXZWlsLCBKYXNvbiB3cm90ZToNCj4+DQo+
Pj4gTWFyaywgUmFwbGgsIEphcmksIGV0IGFsbCwNCj4+Pg0KPj4+IEkgcmVhbGx5IGFwcHJlY2lh
dGUgdGhlIGNoYW5nZSBpbiBjaGFydGVyIGFuZCBkaXJlY3Rpb24gZm9yIHRoaXMNCj4+PnByb3Bv
c2VkDQo+Pj4gV0cgYW5kIHRoZSBpbnRlcmVzdCB0byBrZWVwIGl0IGdvaW5nLiBJIGJlbGlldmUg
aXQgc2V0cyBhIHBhdGggdGhhdCBpcw0KPj4+IHNjb3BlZCBuYXJyb3cgZW5vdWdoIHRvIHByb3Zp
ZGUgYSB3b3JrcGxhY2UgZm9yIGFjaGlldmFibGUgcmVzdWx0cy4NCj4+Pg0KPj4+IEFzIGEgcHJv
dmlkZXIgd29ya2luZyBvbiB3cml0aW5nLCB0ZXN0aW5nIGFuZCBpbXBsZW1lbnRpbmcgSVB2NiBD
UEUsIEkNCj4+PmNhbg0KPj4+IHJlbGF0ZSBmaXJzdGhhbmQgdGhhdCBnZXR0aW5nIGJhc2ljIElQ
djYgZnVuY3Rpb25hbGl0eSB3b3JraW5nIGluIHRoZQ0KPj4+aG9tZQ0KPj4+IG5ldHdvcmsgaXMg
bm8gc2ltcGxlIGZlYXQgYW5kIGlzIHN0aWxsIGEgd29yayBpbiBwcm9ncmVzcy4gRG9uJ3QgZ2V0
IG1lDQo+Pj4gd3JvbmcsIGJhc2ljIGZ1bmN0aW9uYWxpdHkgaXMgdGhlcmUganVzdCBub3QgYmFr
ZWQuIFdoYXQgc2VlbXMgdmVyeQ0KPj4+IHN0cmFpZ2h0Zm9yd2FyZCBpbiB0aGVvcnkgdHlwaWNh
bGx5IGZhaWxzIGluIGEgbXVsdGl0dWRlIG9mIGNvcm5lcg0KPj4+Y2FzZXMNCj4+PiBpZSByZWFs
aXR5LiBBbmQganVzdCB0byBjbGFyaWZ5IEkgYW0gcmVmZXJyaW5nIHRvIGEgc2luZ2xlIC82NCBz
dWJuZXQNCj4+PiB0b3BvbG9neSB3aXRoIG5vIHJvdXRpbmcuDQo+Pj4NCj4+PiBJZiB3ZSBjYW4g
c3RheSBmb2N1c3NlZCBvbiBzb2x2aW5nIGp1c3QgdGhlIGJhc2ljcyBmb3IgdGhlIGZpdmUgYXJl
YXMNCj4+PiBpbmNsdWRlZCwgSSBiZWxpZXZlIGl0IHdpbGwgYmUgaGVscGZ1bC4gVGhlIG90aGVy
IHJlY29tbWVuZGF0aW9uIHdvdWxkDQo+Pj5iZQ0KPj4+IHRvIHdvcmsgYXMgZXhwZWRpdGlvdXNs
eSBhcyBwb3NzaWJsZS4gUHJvdmlkZXJzIGluIHRoZSBwcm9jZXNzIG9mDQo+Pj4gZGVwbG95aW5n
IElQdjYgbm93IGFyZSBhbHJlYWR5IGRlZXAgaW50byB0aGlzIGFuYWx5c2lzIGFuZCBkZXZlbG9w
bWVudA0KPj4+IHdpdGggdGhlaXIgdmVuZG9ycy4gSWYgd2Ugd2FpdCB0b28gbG9uZyB0aGVuIHRo
ZXNlIHRvcGljcyB3aWxsIGJlDQo+Pj5zb2x2ZWQNCj4+PiB3aXRoIGludGVyb3BlcmFiaWxpdHkg
YSBwb3NzaWJsZSBjYXN1YWx0eS4NCj4+Pg0KPj4+IEZXSVcsIEkgd291bGQgYWxzbyBhZGQgdGhh
dCB0aGUgZml2ZSB0b3BpY3MgaW4gdGhlIGNoYXJ0ZXIgYXJlIGFsc28NCj4+Pmxpc3RlZA0KPj4+
IGluIG9yZGVyDQo+Pj4gT2YgcHJpb3JpdHkgYXQgbGVhc3QgZm9yIG1lLg0KPj4+DQo+Pj4NCj4+
PiBUaGFua3MsDQo+Pj4NCj4+PiBKYXNvbg0KPj4+DQo+Pj4NCj4+PiBPbiA2LzI5LzExIDU6NDYg
QU0sICJNYXJrIFRvd25zbGV5IiA8bWFya0B0b3duc2xleS5uZXQ+IHdyb3RlOg0KPj4+DQo+Pj4+
DQo+Pj4+IEFsbCwNCj4+Pj4NCj4+Pj4gQXBvbG9naWVzIGZvciBkb3VibGUtcG9zdGluZyBpZiB0
aGVyZSBhcmUgZm9sa3MgdGhhdCBhcmUgc3Vic2NyaWJlZCB0bw0KPj4+PiBob21lZ2F0ZUBpZXRm
Lm9yZyBhbmQgZnVuQGlldGYub3JnLiBJJ20gaG9waW5nIHNvb24gdGhhdCBzb21lb25lIHdpbGwN
Cj4+Pj4gZmluYWxseSBjcmVhdGUgaG9tZW5ldEBpZXRmLm9yZyBhbmQgY29uc29saWRhdGUgdGhl
IG1lbWJlcnNoaXANCj4+Pj4gYWNjb3JkaW5nbHkuDQo+Pj4+DQo+Pj4+IEluIHRoZSBjaGFydGVy
IHByb3Bvc2FsIGJlbG93LCBJIHRoaW5rIHlvdSB3aWxsIHNlZSBhIGxvdCBvZg0KPj4+PnNpbWls
YXJpdHkNCj4+Pj4gd2l0aCB0aGUgY29uc2Vuc3VzIHdlIGFjaGlldmVkIG9uIHRoZSBob21lZ2F0
ZSBsaXN0IGxhc3QgeWVhci4gSmFyaQ0KPj4+Pmhhcw0KPj4+PiB0YWtlbiB0aGF0LCBmZWVkYmFj
ayBmcm9tIHRoZSBJRVNHLCBJQUIsIG1lbWJlcnMgb2YgdGhlDQo+Pj4+SVAtRGlyZWN0b3JhdGUs
DQo+Pj4+IHY2b3BzIGNoYWlycywgZXRjLiBhbmQgc2hhcGVkIGl0IHRvd2FyZHMgc29tZXRoaW5n
IG1vcmUgZm9jdXNlZCBvbiB0aGUNCj4+Pj4gSW50ZXJuZXQgKGFuZCBSb3V0aW5nKSBhcmVhLCBh
cyB3ZWxsIGFzIElQdjYuIEkgYmVsaWV2ZSBoZSBhbmQgUmFscGgNCj4+Pj5ib3RoDQo+Pj4+IGhh
dmUgYSBncmVhdCBkZWFsIG9mIGNvbmZpZGVuY2UgdGhhdCB0aGlzIGlzIHNvbWV0aGluZyB0aGF0
IGlzIHZlcnkNCj4+Pj4gaW1wb3J0YW50IHRvIHRoZSBpbmR1c3RyeSwgYW5kIHRoYXQgdGhlIElF
VEYgaGFzIGEgY3JpdGljYWwgcm9sZSB0bw0KPj4+PnBsYXkuDQo+Pj4+DQo+Pj4+IFNvLCBtYWtl
IG5vIG1pc3Rha2UsIHdoZXRoZXIgd2UgZW5kIHVwIGFzIGEgV0cgb3IgYSBCb0YgYmV0d2VlbiBu
b3cNCj4+Pj5hbmQNCj4+Pj4gUXVlYmVjLCAid2UncmUgYmFjayIgLSBwbGVhc2Ugc2VuZCBjb21t
ZW50cywgYW5kIG1ha2UgeW91ciB0cmF2ZWwgb3INCj4+Pj4gcmVtb3RlLWF0dGVuZGFuY2UgcGxh
bnMgYWNjb3JkaW5nbHkgaWYgeW91IHdhbnQgdG8gcGFydGljaXBhdGUuDQo+Pj4+DQo+Pj4+IEph
cmkgaGFzIGFza2VkIG1lIHRvIGNvLWNoYWlyIHRoZSBzZXNzaW9uIGluIFF1ZWJlYy4gQXMgc3Vj
aCwgSSdkDQo+Pj4+bGlrZSB0bw0KPj4+PiB0YWtlIHJlcXVlc3RzIGZvciBwcmVzZW50YXRpb24g
dGltZSBub3cuIEphcmkgYW5kIEkgd2lsbCBsaWtlbHkgYmVnaW4NCj4+Pj50aGUNCj4+Pj4gc2Vz
c2lvbiB3aXRoIGEgc2NvcGluZyBvdmVydmlldywgYXMgd2VsbCBhcyBhIGZpcnN0IGN1dCBhdCBh
bg0KPj4+PiBhcmNoaXRlY3R1cmUgZnJhbWV3b3JrLCBidXQgdGhlcmUgc2hvdWxkIGJlIHNvbWUg
dGltZSBmb3IgYSBmZXcgb3RoZXINCj4+Pj4gaXRlbXMuIFdoZW4gc3VibWl0dGluZyB5b3VyIHJl
cXVlc3QsIHBsZWFzZSBpZGVudGlmeSB3aGljaCBvZiB0aGUgNQ0KPj4+PmFyZWFzDQo+Pj4+IGJl
bG93IHlvdSB0aGluayB5b3VyIHdvcmsgYXBwbGllcyB0byBhcyB3ZWxsIGFzIHRoZSBpbnRlcm5l
dC1kcmFmdCwgb2YNCj4+Pj4gY291cnNlLg0KPj4+Pg0KPj4+PiBUaGFua3MsIGFuZCBzZWUgeW91
IG9uIHRoZSBsaXN0IGFuZCBpbiBRdWViZWMuDQo+Pj4+DQo+Pj4+IC0gTWFyaw0KPj4+Pg0KPj4+
Pg0KPj4+PiBPbiBKdW4gMjksIDIwMTEsIGF0IDEwOjM1IEFNLCBKYXJpIEFya2tvIHdyb3RlOg0K
Pj4+Pg0KPj4+Pj4gSSB3YW50ZWQgdG8gcHJvdmlkZSBhbiB1cGRhdGUgb2YgdGhlIHNpdHVhdGlv
biB3aXRoIHRoaXMgd29ya2luZw0KPj4+Pj5ncm91cA0KPj4+Pj4gcHJvcG9zYWwuDQo+Pj4+Pg0K
Pj4+Pj4gSE9NRU5FVCBpcyBhIG5ldyB3b3JraW5nIGdyb3VwIHByb3Bvc2FsLCBhIHZhcmlhdGlv
biBvZiB0aGUNCj4+Pj4+IEhPTUVHQVRFL0hPTUVORVQgdGhlbWUgdGhhdCB3ZSBkaXNjdXNzZWQg
bGFzdCB5ZWFyLCBidXQgdGhpcyB0aW1lDQo+Pj4+PiBsb29raW5nIGF0IGl0IGZyb20gYSBkaWZm
ZXJlbnQgYW5nbGUuIFRoZSBvbGQgZWZmb3J0IHdhcyBtb3N0bHkNCj4+Pj4+Zm9jdXNlZA0KPj4+
Pj4gYWJvdXQgd2hhdCBob21lIGdhdGV3YXlzIHNob3VsZCBkbzogZm9yd2FyZGluZywgdHJhbnNw
b3J0LCBhbmQgRE5TDQo+Pj4+PiBwcm94eWluZyBpc3N1ZXMuIFRoZSBuZXcgZWZmb3J0IGlzIGFi
b3V0IGhvbWUgbmV0d29ya3MgdGhlbXNlbHZlcywgaW4NCj4+Pj4+IHBhcnRpY3VsYXIgd2hhdCBr
aW5kIG9mIG5ldHdvcmsgYXJjaGl0ZWN0dXJlIGFuZCBjb25maWd1cmF0aW9uIGlzDQo+Pj4+PiBu
ZWNlc3NhcnkgdG8gc3VwcG9ydCBJUHY2LWJhc2VkIGhvbWUgbmV0d29ya3MuIFdlIHZpZXcgSVB2
NC1iYXNlZA0KPj4+Pj5ob21lDQo+Pj4+PiBuZXR3b3JrcyBhcyAiZG9uZSIgYXQgdGhpcyB0aW1l
IChvciBwZXJoYXBzIGFzICJjYW5ub3QgYmUgY2hhbmdlZA0KPj4+Pj4gYW55d2F5IikuDQo+Pj4+
Pg0KPj4+Pj4gSSBoYXZlIGJlZW4gZGlzY3Vzc2luZyB0aGlzIGVmZm9ydCBpbiB0aGUgYmFja2dy
b3VuZCBmb3IgdGhlIGxhc3QNCj4+Pj4+IGNvdXBsZSBvZiBtb250aCB3aXRoIE1hcmsgVG93bnNs
ZXkgYW5kIG90aGVycywgYW5kIG1vcmUgcHVibGljbHkNCj4+Pj4+c2luY2UNCj4+Pj4+IGVhcmx5
IEp1bmUuIFRoZSBwcm9wb3NhbCBoYXMgYmVlbiBicm91Z2h0IHRvIHRoZSBJRVNHLCBJQUIgYW5k
IHNvbWUNCj4+Pj4+IGRpcmVjdG9yYXRlcyBmb3IgZGlzY3Vzc2lvbiwgYW5kIHdlJ3ZlIGJlZW4g
Z29pbmcgYmFjayBhbmQgZm9ydGgNCj4+Pj4+d2hldGhlcg0KPj4+Pj4gdGhpcyBpcyByZWFkeSB0
byBiZWNvbWUgYSB3b3JraW5nIGdyb3VwIG9yIG5lZWRzIHRvIGJlIHJ1biBhcyBhIEJPRg0KPj4+
Pj5pbg0KPj4+Pj4gUXVlYmVjIENpdHkuIFRoZSBjdXJyZW50IHBsYW4gaXMgdGhhdCB0aGUgd29y
a2luZyBncm91cCBwcm9wb3NhbA0KPj4+Pj5nb2VzIHRvDQo+Pj4+PiBJRVRGLXdpZGUgcmV2aWV3
IHRoaXMgd2VlaywgYW5kIGlmIHRoZSBmZWVkYmFjayBmcm9tIHRoZSBjb21tdW5pdHksDQo+Pj4+
PklBQiwNCj4+Pj4+IGFuZCB0aGUgSUVTRyBpcyBwb3NpdGl2ZSwgd2Ugd2lsbCBjcmVhdGUgdGhl
IHdvcmtpbmcgZ3JvdXAganVzdCBpbg0KPj4+Pj50aW1lDQo+Pj4+PiBmb3IgdGhlIElFVEYuIE90
aGVyd2lzZSwgdGhlIHNsb3QgcmVzZXJ2ZWQgaW4gdGhlIGFnZW5kYSBmb3IgdGhlDQo+Pj4+Pm1l
ZXRpbmcNCj4+Pj4+IHdpbGwgYmUgdXNlZCB0byBydW4gdGhlIHByb3Bvc2FsIGFzIGEgQk9GLg0K
Pj4+Pj4NCj4+Pj4+IEluIGFueSBjYXNlLCBJIHdvdWxkIGxpa2UgdG8gc29saWNpdCBkaXNjdXNz
aW9uIG9uIHRoaXMgdG9waWMsIGFuZA0KPj4+Pj4gcGVyaGFwcyBzb21lIGVhcmx5IGRyYWZ0cyBh
cyB3ZWxsLiBQbGVhc2UgY29tbWVudCBvbiB0aGUgY2hhcnRlciBhdA0KPj4+Pj4gbGVhc3QuDQo+
Pj4+Pg0KPj4+Pj4gTm90ZSB0aGF0IHRoZSBuZXcgcHJvcG9zYWwgd2FzIGNhbGxlZCBGVU4gYXQg
dGhlIHRpbWUgdGhhdCB3ZSBjcmVhdGVkDQo+Pj4+PiB0aGUgbGlzdC4gSXQgaGFzIG5vdyBiZWVu
IHJlbmFtZWQgYmFjayB0byBIT01FTkVUIHRvIGJlIG1vcmUNCj4+Pj4+IGRlc2NyaXB0aXZlLiBU
aGUgbGlzdCB3aWxsIGJlIHJlbmFtZWQgc29vbiBhcyB3ZWxsIChjdXJyZW50DQo+Pj4+PnN1YnNj
cmliZXJzDQo+Pj4+PiB3aWxsIHN0YXkpLg0KPj4+Pj4NCj4+Pj4+IFRoaXMgaXMgdGhlIG1vc3Qg
cmVjZW50IHZlcnNpb24gb2YgdGhlIGNoYXJ0ZXIgd2Ugc2hvdWxkIGRpc2N1c3M6DQo+Pj4+Pg0K
Pj4+Pj4gSG9tZSBOZXR3b3JrcyAoaG9tZW5ldCkNCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pg0KPj4+Pj4gQ3VycmVudCBTdGF0dXM6IFByb3Bvc2VkDQo+
Pj4+PiBMYXN0IEVkaXQ6IFdlZG5lc2RheSwgSnVuZSAyOXRoLCAyMDExDQo+Pj4+Pg0KPj4+Pj4g
Q2hhaXJzOg0KPj4+Pj4gVEJEDQo+Pj4+Pg0KPj4+Pj4gSW50ZXJuZXQgQXJlYSBEaXJlY3RvcnM6
DQo+Pj4+PiBSYWxwaCBEcm9tcyA8cmRyb21zLmlldGZAZ21haWwuY29tPg0KPj4+Pj4gSmFyaSBB
cmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+DQo+Pj4+Pg0KPj4+Pj4gSW50ZXJuZXQgQXJlYSBB
ZHZpc29yOg0KPj4+Pj4gSmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+DQo+Pj4+Pg0K
Pj4+Pj4gUm91dGluZyBBcmVhIFRlY2huaWNhbCBBZHZpc29yOg0KPj4+Pj4gVEJEDQo+Pj4+Pg0K
Pj4+Pj4gU2VjdXJpdHkgQXJlYSBUZWNobmljYWwgQWR2aXNvcjoNCj4+Pj4+IFRCRA0KPj4+Pj4N
Cj4+Pj4+IE1haWxpbmcgTGlzdHM6DQo+Pj4+PiBHZW5lcmFsIERpc2N1c3Npb246IGZ1bkBpZXRm
Lm9yZw0KPj4+Pj4gVG8gU3Vic2NyaWJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL2Z1bg0KPj4+Pj4gQXJjaGl2ZTogaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp
dmUvd2ViL2Z1bg0KPj4+Pj4NCj4+Pj4+IERlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6DQo+
Pj4+Pg0KPj4+Pj4gVGhpcyB3b3JraW5nIGdyb3VwIGZvY3VzZXMgb24gdGhlIGV2b2x2aW5nIG5l
dHdvcmtpbmcgdGVjaG5vbG9neQ0KPj4+Pj4gd2l0aGluIGFuZCBhbW9uZyByZWxhdGl2ZWx5IHNt
YWxsIKn4cmVzaWRlbnRpYWwgaG9tZan3IG5ldHdvcmtzLiBGb3INCj4+Pj4+IGV4YW1wbGUsIGFu
IG9idmlvdXMgdHJlbmQgaW4gaG9tZSBuZXR3b3JraW5nIGlzIHRoZSBwcm9saWZlcmF0aW9uIG9m
DQo+Pj4+PiBuZXR3b3JraW5nIHRlY2hub2xvZ3kgaW4gYW4gaW5jcmVhc2luZ2x5IGJyb2FkIHJh
bmdlIGFuZCBudW1iZXIgb2YNCj4+Pj4+IGRldmljZXMuIFRoaXMgZXZvbHV0aW9uIGluIHNjYWxl
IGFuZCBkaXZlcnNpdHkgc2V0cyBzb21lIHJlcXVpcmVtZW50cw0KPj4+Pj4gb24gSUVURiBwcm90
b2NvbHMuIFNvbWUgb2YgdGhlIHJlbGV2YW50IHRyZW5kcyBpbmNsdWRlOg0KPj4+Pj4NCj4+Pj4+
IG8gTXVsdGlwbGUgc2VnbWVudHM6IFdoaWxlIGxlc3MgY29tcGxleCBMMy10b3Bsb2dpZXMgaW52
b2x2aW5nIGFzIGZldw0KPj4+Pj4gc3VibmV0cyBhcyBwb3NzaWJsZSBhcmUgcHJlZmVycmVkIGlu
IGhvbWUgbmV0d29ya3MgZm9yIGEgdmFyaWV0eSBvZg0KPj4+Pj4gcmVhc29ucyBpbmNsdWRpbmcg
c2ltcGxlciBtYW5hZ2VtZW50IGFuZCBzZXJ2aWNlIGRpc2NvdmVyeSwgdGhlDQo+Pj4+PiBpbnRy
b2R1Y3Rpb24gb2YgbW9yZSB0aGFuIG9uZSBzdWJuZXQgaW50byBhIGhvbWUgbmV0d29yayBpcyBl
bm91Z2gNCj4+Pj4+IHRvIGFkZCBjb21wbGV4aXR5IHRoYXQgbmVlZHMgdG8gYmUgYWRkcmVzc2Vk
LCBhbmQgbXVsdGlwbGUNCj4+Pj4+IGRlZGljYXRlZCBzZWdtZW50cyBhcmUgbmVjZXNzYXJ5IGZv
ciBzb21lIGNhc2VzLiBGb3IgaW5zdGFuY2UsIGENCj4+Pj4+IGNvbW1vbiBmZWF0dXJlIGluIG1v
ZGVybiBob21lIHJvdXRlcnMgaW4gdGhlIGFiaWxpdHkgdG8gc3VwcG9ydA0KPj4+Pj4gYm90aCBn
dWVzdCBhbmQgcHJpdmF0ZSBuZXR3b3JrIHNlZ21lbnRzLiBBbHNvLCBsaW5rIGxheWVyDQo+Pj4+
PiBuZXR3b3JraW5nIHRlY2hub2xvZ3kgaXMgcG9pc2VkIHRvIGJlY29tZSBtb3JlIGhldGVyb2dl
bmVvdXMsIGFzDQo+Pj4+PiBuZXR3b3JrcyBiZWdpbiB0byBlbXBsb3kgYm90aCB0cmFkaXRpb25h
bCBFdGhlcm5ldCB0ZWNobm9sb2d5IGFuZA0KPj4+Pj4gbGluayBsYXllcnMgZGVzaWduZWQgZm9y
IGxvdy1wb3dlcmVkIHNlbnNvciBuZXR3b3Jrcy4gRmluYWxseSwNCj4+Pj4+IHNpbWlsYXIgbmVl
ZHMgZm9yIHNlZ21lbnRhdGlvbiBtYXkgb2NjdXIgaW4gb3RoZXIgY2FzZXMsIHN1Y2ggYXMNCj4+
Pj4+IHNlcGFyYXRpbmcgYnVpbGRpbmcgY29udHJvbCBvciBjb3Jwb3JhdGUgZXh0ZW5zaW9ucyBm
cm9tIHRoZQ0KPj4+Pj4gSW50ZXJuZXQgYWNjZXNzIG5ldHdvcmsuIERpZmZlcmVudCBzZWdtZW50
cyBtYXkgYmUgYXNzb2NpYXRlZCB3aXRoDQo+Pj4+PiBzdWJuZXRzIHRoYXQgaGF2ZSBkaWZmZXJl
bnQgcm91dGluZyBhbmQgc2VjdXJpdHkgcG9saWNpZXMuDQo+Pj4+Pg0KPj4+Pj4gbyBTZXJ2aWNl
IHByb3ZpZGVycyBhcmUgZGVwbG95aW5nIElQdjYsIGFuZCBzdXBwb3J0IGZvciBJUHY2IGlzDQo+
Pj4+PiBpbmNyZWFzaW5nbHkgYXZhaWxhYmxlIGluIGhvbWUgZ2F0ZXdheSBkZXZpY2VzLiBXaGls
ZSBJUHY2IHJlc2VtYmxlcw0KPj4+Pj4gSVB2NCBpbiBtYW55IHdheXMsIGl0IGNoYW5nZXMgYWRk
cmVzcyBhbGxvY2F0aW9uIHByaW5jaXBsZXMgYW5kDQo+Pj4+PmFsbG93cw0KPj4+Pj4gZGlyZWN0
IElQIGFkZHJlc3NhYmlsaXR5IGFuZCByb3V0aW5nIHRvIGRldmljZXMgaW4gdGhlIGhvbWUgZnJv
bSB0aGUNCj4+Pj4+IEludGVybmV0LiBUaGlzIGlzIGEgcHJvbWlzaW5nIGFyZWEgaW4gSVB2NiB0
aGF0IGhhcyBwcm92ZWQNCj4+Pj4+Y2hhbGxlbmdpbmcNCj4+Pj4+IGluIElQdjQgd2l0aCB0aGUg
cHJvbGlmZXJhdGlvbiBvZiBOQVQuDQo+Pj4+Pg0KPj4+Pj4gbyBFbmQtdG8tZW5kIGNvbW11bmlj
YXRpb24gaXMgYm90aCBhbiBvcHBvcnR1bml0eSBhbmQgYSBjb25jZXJuIGFzIGl0DQo+Pj4+PiBl
bmFibGVzIG5ldyBhcHBsaWNhdGlvbnMgYnV0IGFsc28gZXhwb3NlcyBub2RlcyBpbiB0aGUgaW50
ZXJuYWwNCj4+Pj4+IG5ldHdvcmtzIHRvIHJlY2VpcHQgb2YgdW53YW50ZWQgdHJhZmZpYyBmcm9t
IHRoZSBJbnRlcm5ldC4gRmlyZXdhbGxzDQo+Pj4+PiB0aGF0IHJlc3RyaWN0IGluY29taW5nIGNv
bm5lY3Rpb25zIG1heSBiZSB1c2VkIHRvIHByZXZlbnQgZXhwb3N1cmUsDQo+Pj4+PiBob3dldmVy
LCB0aGlzIHJlZHVjZXMgdGhlIGVmZmljYWN5IG9mIGVuZC10by1lbmQgY29ubmVjdGl2aXR5IHRo
YXQNCj4+Pj4+IElQdjYgaGFzIHRoZSBwb3RlbnRpYWwgdG8gcmVzdG9yZS4NCj4+Pj4+DQo+Pj4+
PiBIb21lIG5ldHdvcmtzIG5lZWQgdG8gcHJvdmlkZSB0aGUgdG9vbHMgdG8gaGFuZGxlIHRoZXNl
IHNpdHVhdGlvbnMgaW4NCj4+Pj4+IGEgbWFubmVyIGFjY2Vzc2libGUgdG8gYWxsIHVzZXJzIG9m
IGhvbWUgbmV0d29ya3MuIE1hbnVhbA0KPj4+Pj4gY29uZmlndXJhdGlvbiBpcyByYXJlbHksIGlm
IGF0IGFsbCwgcG9zc2libGUuIFRoZSBwdXJwb3NlIG9mIHRoaXMNCj4+Pj4+IHdvcmtpbmcgZ3Jv
dXAgaXMgdG8gZm9jdXMgb24gdGhpcyBldm9sdXRpb24sIGluIHBhcnRpY3VsYXIgYXMgaXQNCj4+
Pj4+IGFkZHJlc3NlcyB0aGUgaW50cm9kdWN0aW9uIG9mIElQdjYsIGJ5IGRldmVsb3BpbmcgYW4g
YXJjaGl0ZWN0dXJlDQo+Pj4+PiBhZGRyZXNzaW5nIHRoaXMgZnVsbCBzY29wZSBvZiByZXF1aXJl
bWVudHM6DQo+Pj4+Pg0KPj4+Pj4gbyBwcmVmaXggY29uZmlndXJhdGlvbiBmb3Igcm91dGVycw0K
Pj4+Pj4gbyBtYW5hZ2luZyByb3V0aW5nDQo+Pj4+PiBvIG5hbWUgcmVzb2x1dGlvbg0KPj4+Pj4g
byBzZXJ2aWNlIGRpc2NvdmVyeQ0KPj4+Pj4gbyBuZXR3b3JrIHNlY3VyaXR5DQo+Pj4+Pg0KPj4+
Pj4gVGhlIHRhc2sgb2YgdGhlIGdyb3VwIGlzIHRvIHByb2R1Y2UgYW4gYXJjaGl0ZWN0dXJlIGRv
Y3VtZW50IHRoYXQNCj4+Pj4+IG91dGxpbmVzIGhvdyB0byBjb25zdHJ1Y3QgaG9tZSBuZXR3b3Jr
cyBpbnZvbHZpbmcgbXVsdGlwbGUgcm91dGVycw0KPj4+Pj5hbmQNCj4+Pj4+IHN1Ym5ldHMuIFRo
aXMgZG9jdW1lbnQgaXMgZXhwZWN0ZWQgdG8gYXBwbHkgdGhlIElQdjYgYWRkcmVzc2luZw0KPj4+
Pj4gYXJjaGl0ZWN0dXJlLCBwcmVmaXggZGVsZWdhdGlvbiwgZ2xvYmFsIGFuZCBVTEEgYWRkcmVz
c2VzLCBzb3VyY2UNCj4+Pj4+IGFkZHJlc3Mgc2VsZWN0aW9uIHJ1bGVzIGFuZCBvdGhlciBleGlz
dGluZyBjb21wb25lbnRzIG9mIHRoZSBJUHY2DQo+Pj4+PiBhcmNoaXRlY3R1cmUuIFRoZSBhcmNo
aXRlY3R1cmUgZG9jdW1lbnQgc2hvdWxkIGRyaXZlIHdoYXQgcHJvdG9jb2xzDQo+Pj4+PiBjaGFu
Z2VzLCBpZiBhbnksIGFyZSBuZWNlc3NhcnkuIFNwZWNpZmljIHByb3RvY29sIHdvcmsgZGVzY3Jp
YmVkDQo+Pj4+PmJlbG93DQo+Pj4+PiBpcyBleHBlY3RlZCB0byBiZSB3aXRoaW4gdGhlIHNjb3Bl
IG9mIHRoZSB3b3JraW5nIGdyb3VwIG9uZSB0aGUNCj4+Pj4+IGFyY2hpdGVjdHVyZSB3b3JrIGlz
IGNvbXBsZXRlLiBIb3dldmVyLCB0aGUgZ3JvdXAgaXMgcmVxdWlyZWQgdG8NCj4+Pj4+IHJldmll
dyBpdHMgY2hhcnRlciBhbmQgbWlsZXN0b25lcyB3aXRoIHRoZSBJRVNHIGFuZCBJRVRGIGNvbW11
bml0eQ0KPj4+Pj4gYmVmb3JlIHN1Ym1pdHRpbmcgZG9jdW1lbnRzIHRoYXQgbWFrZSBwcm90b2Nv
bCBjaGFuZ2VzLiBJdCBpcw0KPj4+Pj5leHBlY3RlZA0KPj4+Pj4gdGhhdCB0aGUgZ3JvdXAgaGFz
IHRvIGRpc2N1c3Mgc29tZSBvZiB0aGUgYmVsb3cgc29sdXRpb25zLCBob3dldmVyLA0KPj4+Pj5p
bg0KPj4+Pj4gb3JkZXIgdG8gY29tcGxldGUgdGhlIGFyY2hpdGVjdHVyZSB3b3JrLg0KPj4+Pj4N
Cj4+Pj4+IFRoZSBncm91cCB3aWxsIGFwcGx5IGV4aXN0aW5nIHByb3RvY29scyB0byBoYW5kbGUg
dGhlIGZpdmUNCj4+Pj4+IHJlcXVpcmVtZW50cyBhYm92ZS4gRm9yIHByZWZpeCBjb25maWd1cmF0
aW9uLCBleGlzdGluZyBwcm90b2NvbHMgYXJlDQo+Pj4+PiBsaWtlbHkgc3VmZmljaWVudCwgYW5k
IGF0IHdvcnN0IG1heSBuZWVkIHNvbWUgc21hbGwgZW5oYW5jZW1lbnRzLA0KPj4+Pj5zdWNoDQo+
Pj4+PiBhcyBuZXcgb3B0aW9ucy4gRm9yIGF1dG9tYXRpYyByb3V0aW5nLCBpdCBpcyBleHBlY3Rl
ZCB0aGF0IGV4aXN0aW5nDQo+Pj4+PiByb3V0aW5nIHByb3RvY29scyBjYW4gYmUgdXNlZCBhcyBp
cywgaG93ZXZlciwgYSBuZXcgbWVjaGFuaXNtIG1heSBiZQ0KPj4+Pj4gbmVlZGVkIGluIG9yZGVy
IHRvIHR1cm4gYSBzZWxlY3RlZCBwcm90b2NvbCBvbiBieSBkZWZhdWx0LiBGb3IgbmFtZQ0KPj4+
Pj4gcmVzb2x1dGlvbiBhbmQgc2VydmljZSBkaXNjb3ZlcnksIGV4dGVuc2lvbnMgdG8gZXhpc3Rp
bmcNCj4+Pj4+IG11bHRpY2FzdC1iYXNlZCBuYW1lIHJlc29sdXRpb24gcHJvdG9jb2xzIGFyZSBu
ZWVkZWQgdG8gZW5hYmxlIHRoZW0NCj4+Pj4+dG8NCj4+Pj4+IHdvcmsgYWNyb3NzIHN1Ym5ldHMu
DQo+Pj4+Pg0KPj4+Pj4gRm9yIG5ldHdvcmsgc2VjdXJpdHksIHRoZSBncm91cCBzaGFsbCBkb2N1
bWVudCB0aGUgY29uY2VwdCBvZg0KPj4+Pj4gImFkdmFuY2VkIHNlY3VyaXR5IiBhcyBhIGZ1cnRo
ZXIgZGV2ZWxvcG1lbnQgb2YgInNpbXBsZSBzZWN1cml0eSINCj4+Pj4+ZnJvbQ0KPj4+Pj4gUkZD
IDYwOTIuIFRoZSBtYWluIGdvYWwgb2YgdGhpcyB3b3JrIGlzIHRvIGVuYWJsZSBhIHNlY3VyaXR5
IHBvbGljeQ0KPj4+Pj4gdGhhdCBhZGFwdHMgdG8gSVB2NiB0aHJlYXRzIGFzIHRoZXkgZW1lcmdl
LCB0YWtpbmcgaW50byBhY2NvdW50IG5vdA0KPj4+Pj4gb25seSB0cmFmZmljIGZyb20gdGhlIElu
dGVybmV0IGF0IGxhcmdlLCBidXQgd2l0aGluIGFuZCBsZWF2aW5nIHRoZQ0KPj4+Pj4gaG9tZSBu
ZXR3b3JrIGl0c2VsZi4NCj4+Pj4+DQo+Pj4+PiBJdCBpcyBleHBlY3RlZCB0aGF0IHRoZSB3b3Jr
aW5nIGdyb3VwIHdpbGwgZGVmaW5lIGEgc2V0IG9mIHByb3RvY29sDQo+Pj4+PiBzcGVjaWZpY2F0
aW9ucyB0byBhY2NvbXBsaXNoIHRoZSBmaXZlIHJlcXVpcmVtZW50cyBmcm9tDQo+Pj4+PiBhYm92
ZS4gSG93ZXZlciwgaXQgaXMgbm90IGluIHRoZSBzY29wZSBvZiB0aGUgd29ya2luZyBncm91cCB0
byBkZWZpbmUNCj4+Pj4+IGVudGlyZWx5IG5ldyByb3V0aW5nIHByb3RvY29scyBvciBhZGRyZXNz
IGFsbG9jYXRpb24gcHJvdG9jb2xzLiBBcw0KPj4+Pj4gbm90ZWQsIGFkZGl0aW9uYWwgb3B0aW9u
cyBvciBvdGhlciBzbWFsbCBleHRlbnNpb25zIG1heSBiZSBuZWNlc3NhcnkNCj4+Pj4+IHRvIHVz
ZSB0aGUgZXhpc3RpbmcgcHJvdG9jb2xzIGluIHRoZXNlIG5ldyBjb25maWd1cmF0aW9uIHRhc2tz
LiBUaGUNCj4+Pj4+IHdvcmtpbmcgZ3JvdXAgc2hhbGwgYWxzbyBub3QgbWFrZSBhbnkgY2hhbmdl
cyB0byBJUHY2IHByb3RvY29scyBvcg0KPj4+Pj4gYWRkcmVzc2luZyBhcmNoaXRlY3R1cmUuIFBy
ZWZpeCBjb25maWd1cmF0aW9uLCByb3V0aW5nLCBhbmQgc2VjdXJpdHkNCj4+Pj4+IHJlbGF0ZWQg
d29yayBzaGFsbCBub3QgY2F1c2UgYW55IGNoYW5nZXMgdGhhdCBhcmUgbm90IGJhY2t3YXJkcw0K
Pj4+Pj4gY29tcGF0aWJsZSB0byBleGlzdGluZyBJUHY2IGhvc3RzLiBUaGVyZSBtYXkgYmUgaG9z
dCB2aXNpYmxlIGNoYW5nZXMNCj4+Pj4+IGluIHRoZSB3b3JrIG9uIG5hbWluZyBhbmQgZGlzY292
ZXJ5IHByb3RvY29scywgaG93ZXZlci4gSW4gaXRzDQo+Pj4+PmRlc2lnbiwNCj4+Pj4+IHRoZSB3
b3JraW5nIGdyb3VwIHNoYWxsIGFsc28gY29uc2lkZXIgc2VjdXJpdHkgYXNwZWN0cyBhbmQgdGhl
IGltcGFjdA0KPj4+Pj4gb24gbWFuYWdlYWJpbGl0eS4gVGhlIG1haW4gZm9jdXMgb2YgdGhlIHdv
cmtpbmcgZ3JvdXAgaXMgaG9tZQ0KPj4+Pj4gbmV0d29ya3MsIGJ1dCB0aGUgZ3JvdXAncyByZXN1
bHRzIG1heSBhbHNvIGZpbmQgYXBwbGljYXRpb25zIGluIG90aGVyDQo+Pj4+PiBzbWFsbCBuZXR3
b3Jrcy4NCj4+Pj4+DQo+Pj4+PiBUaGUgd29ya2luZyBncm91cCB3aWxsIGxpYWlzZSB3aXRoIHRo
ZSByZWxldmFudCBJRVRGIHdvcmtpbmcNCj4+Pj4+IGdyb3Vwcy4gSW4gcGFydGljdWxhciwgdGhl
IGdyb3VwIHNob3VsZCB3b3JrIGNsb3NlbHkgd2l0aCB0aGUgVjZPUFMNCj4+Pj4+IHdvcmtpbmcg
Z3JvdXAsIHJldmlldyBhbnkgdXNlIG9yIGV4dGVuc2lvbiBvZiBESENQIHdpdGggdGhlIERIQw0K
Pj4+Pj4gd29ya2luZyBncm91cCwgYW5kIHdvcmsgd2l0aCBhZGRpdGlvbmFsIEROUyByZXF1aXJl
bWVudHMgd2l0aCB0aGUNCj4+Pj4+IEROU0VYVCBhbmQgRE5TT1Agd29ya2luZyBncm91cHMuIElm
IGl0IHR1cm5zIG91dCB0aGF0IGFkZGl0aW9uYWwNCj4+Pj4+IG9wdGlvbnMgYXJlIG5lZWRlZCBm
b3IgYSByb3V0aW5nIHByb3RvY29sLCB0aGV5IHdpbGwgYmUgZGV2ZWxvcGVkIGluDQo+Pj4+PiB0
aGUgYXBwcm9wcmlhdGUgUm91dGluZyBBcmVhIHdvcmtpbmcgZ3JvdXAsIHdpdGggdGhlIEhPTUVO
RVQgd29ya2luZw0KPj4+Pj4gZ3JvdXAgcHJvdmlkaW5nIHRoZSBhcmNoaXRlY3R1cmUgYW5kIHJl
cXVpcmVtZW50cyBmb3Igc3VjaA0KPj4+Pj4gZW5oYW5jZW1lbnRzLiBUaGUgd29ya2luZyBncm91
cCB3aWxsIGFsc28gbGlhc2Ugd2l0aCBleHRlcm5hbA0KPj4+Pj4gc3RhbmRhcmRzIGJvZGllcyB3
aGVyZSBpdCBpcyBleHBlY3RlZCB0aGF0IHRoZXJlIGFyZSBub3JtYXRpdmUNCj4+Pj4+IGRlcGVu
ZGVuY2llcyBiZXR3ZWVuIHRoZSBzcGVjaWZpY2F0aW9ucyBvZiB0aGUgdHdvIGJvZGllcy4NCj4+
Pj4+IEl0IGlzIGV4cGVjdGVkIHRoYXQgaW4gdGhlIGFyY2hpdGVjdHVyZSBkZWZpbml0aW9uIHN0
YWdlIGxpYWlzaW5nDQo+Pj4+PiB3aXRoIHRoZSBCcm9hZGJhbmQgRm9ydW0sIERMTkEsIGFuZCBV
UG5QIEZvcnVtIGlzIG5lY2Vzc2FyeS4NCj4+Pj4+DQo+Pj4+PiBNaWxlc3RvbmVzOg0KPj4+Pj4N
Cj4+Pj4+IEp1bCAyMDExIEZvcm1hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cA0KPj4+Pj4gU2Vw
IDIwMTEgRmlyc3QgV0cgZHJhZnQgb24gdGhlIGFyY2hpdGVjdHVyZQ0KPj4+Pj4gRGVjIDIwMTEg
U3VibWlzc2lvbiBvZiB0aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0IHRvIHRoZSBJRVNHIGFzDQo+Pj4+
PiBJbmZvcm1hdGlvbmFsIFJGQw0KPj4+Pj4gRGVjIDIwMTEgQ2hhcnRlciByZS1ldmFsdWF0aW9u
IGJhc2VkIG9uIHRoZSBhcmNoaXRlY3R1cmUgd29yaw0KPj4+Pj4gRGVjIDIwMTEgRmlyc3QgV0cg
ZHJhZnQgb24gcHJlZml4IGNvbmZpZ3VyYXRpb24NCj4+Pj4+IERlYyAyMDExIEZpcnN0IFdHIGRy
YWZ0IG9uIHJvdXRpbmcNCj4+Pj4+IEphbiAyMDEyIEZpcnN0IFdHIGRyYWZ0IG9uIG5hbWUgcmVz
b2x1dGlvbg0KPj4+Pj4gRmViIDIwMTIgRmlyc3QgV0cgZHJhZnQgb24gc2VydmljZSBkaXNjb3Zl
cnkNCj4+Pj4+IEZlYiAyMDEyIEZpcnN0IFdHIGRyYWZ0IG9uIHBlcmltZXRlciBzZWN1cml0eQ0K
Pj4+Pj4gRmViIDIwMTIgU3RhcnQgb2Ygcm91dGluZyByZWxhdGVkIHdvcmsgaW4gdGhlIHJlbGV2
YW50IHJvdXRpbmcgYXJlYQ0KPj4+Pj4gd29ya2luZyBncm91cCwgaWYgbmVlZGVkDQo+Pj4+PiBN
YXIgMjAxMiBTdWJtaXNzaW9uIG9mIHRoZSBwcmVmaXggY29uZmlndXJhdGlvbiBkcmFmdCB0byB0
aGUgSUVTRyBhcw0KPj4+Pj4gU3RhbmRhcmRzIFRyYWNrIFJGQw0KPj4+Pj4gQXByIDIwMTIgU3Vi
bWlzc2lvbiBvZiB0aGUgcm91dGluZyBkcmFmdCB0byB0aGUgSUVTRyBhcyBJbmZvcm1hdGlvbmFs
DQo+Pj4+PiBSRkMNCj4+Pj4+IFNlcCAyMDEyIFN1Ym1pc3Npb24gb2YgdGhlIG5hbWUgcmVzb2x1
dGlvbiBkcmFmdCB0byB0aGUgSUVTRyBhcw0KPj4+Pj4gU3RhbmRhcmRzIFRyYWNrIFJGQw0KPj4+
Pj4gTm92IDIwMTIgU3VibWlzc2lvbiBvZiB0aGUgc2VydmljZSBkaXNjb3ZlcnkgZHJhZnQgdG8g
dGhlIElFU0cgYXMNCj4+Pj4+IFN0YW5kYXJkcyBUcmFjayBSRkMNCj4+Pj4+IERlYyAyMDEyIFN1
Ym1pc3Npb24gb2YgdGhlIHBlcmltZXRlciBzZWN1cml0eSBkcmFmdCB0byB0aGUgSUVTRyBhcw0K
Pj4+Pj4gSW5mb3JtYXRpb25hbCBSRkMNCj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gZnVuIG1haWxpbmcgbGlzdA0KPj4+
Pj4gZnVuQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2Z1bg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPj4+PiBmdW4gbWFpbGluZyBsaXN0DQo+Pj4+IGZ1bkBpZXRmLm9yZw0KPj4+
PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Z1bg0KPj4+DQo+Pj4NCj4+
PiBUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1l
IFdhcm5lciBDYWJsZQ0KPj4+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZp
bGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdA0KPj4+dG8gY29weXJpZ2h0IGJlbG9uZ2lu
ZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQNCj4+PnNvbGVs
eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMN
Cj4+PmFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0
aGlzIEUtbWFpbCwgeW91DQo+Pj5hcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWlu
YXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3INCj4+PmFjdGlvbiB0YWtlbiBpbiByZWxh
dGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMNCj4+PkUtbWFp
bCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZl
IHJlY2VpdmVkDQo+Pj50aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu
ZGVyIGltbWVkaWF0ZWx5IGFuZA0KPj4+cGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBh
bmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueQ0KPj4+cHJpbnRvdXQuDQo+Pg0KPj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IGZ1biBt
YWlsaW5nIGxpc3QNCj4+IGZ1bkBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9mdW4NCj4NCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRh
Y2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1h
dGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNv
cHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGlu
dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g
d2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp
ZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNz
ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxh
dGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlz
IHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVj
ZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l
ZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkg
b2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg==

From moore@network-heretics.com  Fri Jul  1 06:36:35 2011
Return-Path: <moore@network-heretics.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 8485011E8148; Fri,  1 Jul 2011 06:36:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.569
X-Spam-Level: 
X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 oi6MpFJXu2Hr; Fri,  1 Jul 2011 06:36:34 -0700 (PDT)
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5406821F84D7; Fri,  1 Jul 2011 06:36:14 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id 5552B20905; Fri,  1 Jul 2011 09:36:12 -0400 (EDT)
Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute4.internal (MEProxy); Fri, 01 Jul 2011 09:36:12 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=subject:mime-version:content-type:from:in-reply-to:date:cc:content-transfer-encoding:message-id:references:to; s=smtpout; bh=qpQfdnE3I93odyBFsVX+LbxFeGs=; b=lUGVFN02KT0lSochgz5ZpIhKBdjHgELi0QT1TSItpDuRMfgJ29blkR+YfktT/xUZuV86O+fdGjB/jlNanGfWhjtAxRlKxrMy5DwPp8Bff3WcTWtVnVlDhJDhQHNWBrkTMrg650AZdsyRCFY43LHJtukQ6BkGyE/CWHP+kLCKV3k=
X-Sasl-enc: i0cKhgjK5+moYNIol8osIEUhU+TVYZyUBERv5RehBeVl 1309527371
Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 3E91A40444B; Fri,  1 Jul 2011 09:36:11 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <0B6FEF9D-430B-4C56-BB21-40C5ED888B51@townsley.net>
Date: Fri, 1 Jul 2011 09:35:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <A8AB09DB-AD86-4DB9-8980-53759EB2F1B9@network-heretics.com>
References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <alpine.DEB.2.00.1106300707370.19581@uplift.swm.pp.se> <4E0C1CF8.7090601@gont.com.ar> <alpine.DEB.2.00.1106300923280.19581@uplift.swm.pp.se> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> <DC5C1553-38E9-4853-9AEA-61FC34FC5EC8@network-heretics.com> <0B6FEF9D-430B-4C56-BB21-40C5ED888B51@townsley.net>
To: Mark Townsley <mark@townsley.net>
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Fri, 01 Jul 2011 07:02:54 -0700
Cc: IETF Discussion <ietf@ietf.org>, homegate@ietf.org, fun@ietf.org
Subject: Re: [homegate] HOMENET working group proposal
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: Fri, 01 Jul 2011 13:36:35 -0000

On Jul 1, 2011, at 4:53 AM, Mark Townsley wrote:

> The idea is not to go out of our way for IPv4, but if the topic is IP =
agnostic anyway, so be it. To be clear, there is no *requirement* to =
support IPv4 here. However, there is no requirement to avoid IPv4 *if* =
it doesn't cause significant concession in the IPv6 design either.
>=20
> This cuts both ways, if there is something that is working well in =
IPv4 that we need to carry over to IPv6 with simple extensions, we'll do =
that and capitalizing on that running-code should be considered a good =
thing. We don't want to invent new v6 protocols from scratch that don't =
work with IPv4 when there is no need. For example (and I think this is =
hinted at in the charter), we might use naming and service discovery =
that already exists for IPv4, adapted the the v6 homenet. This doesn't =
mean we need to re-invent a v6-only naming system from scratch - i'd =
much rather use one that is there, which very well may support v4 and =
v6.=20
>=20
>>=20
>> please don't constrain home networks to work only within the confines =
of IPv4 brain damage.
>=20
> What I think I am saying here is that we will do our best to perform =
as if our brains are not damaged, and equally try to avoid damaging our =
brains in the process.

+1

Keith


From rdroms.ietf@gmail.com  Fri Jul  1 07:26:36 2011
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 0B24421F84FA; Fri,  1 Jul 2011 07:26:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.132
X-Spam-Level: 
X-Spam-Status: No, score=-103.132 tagged_above=-999 required=5 tests=[AWL=-0.133, 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 qXBsrowEFGIh; Fri,  1 Jul 2011 07:26:31 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50EB621F84F9; Fri,  1 Jul 2011 07:26:24 -0700 (PDT)
Received: by pzk5 with SMTP id 5so3894207pzk.31 for <multiple recipients>; Fri, 01 Jul 2011 07:26:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0piBSHXuBrcJLTFiQobDEzUVldrU7/vidaH69GGMVUA=; b=YYURJTV6h1KTmWHUcNlHio2A5LrwyNtMuAMYvFd0plh630vYrxpI4nqMpoyU5FXy4K 7P4Guut+92ZH7QP+Ob2LVWmcH+vMqZZ3wd/wY8Z+M8IsE6NW7RmM9QhvSzKbcFBi1InU 9kaFP9pjjomyK0zOdhEh++PdzrG0OC8CSW6WE=
Received: by 10.142.48.10 with SMTP id v10mr1461479wfv.185.1309530383831; Fri, 01 Jul 2011 07:26:23 -0700 (PDT)
Received: from [10.21.108.95] (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id m7sm1999537pbk.38.2011.07.01.07.26.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 07:26:22 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <CA3341C2.4C55%jason.weil@twcable.com>
Date: Fri, 1 Jul 2011 10:26:13 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <5A77C1B3-59BF-4B23-ACD0-A5C3CD9E954D@gmail.com>
References: <CA3341C2.4C55%jason.weil@twcable.com>
To: "Weil, Jason" <jason.weil@twcable.com>
X-Mailer: Apple Mail (2.1084)
Cc: "fun@ietf.org" <fun@ietf.org>, "homegate@ietf.org" <homegate@ietf.org>, "JP Vasseur \(jvasseur\)" <jvasseur@cisco.com>
Subject: Re: [homegate] [fun] status of the homenet effort
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: Fri, 01 Jul 2011 14:26:36 -0000

On Jul 1, 2011, at 9:32 AM 7/1/11, Weil, Jason wrote:

>=20
>=20
> On 7/1/11 4:06 AM, "Mark Townsley" <mark@townsley.net> wrote:
>=20
>>=20
>> On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote:
>>=20
>>> I also think that this deals with an important topic and the list of
>>> items listed on the proposed charter are quite relevant. I'm just =
not
>>> entirely clear on the "routing component": are you referring to:
>>> * A requirement document for Routing in the home?
>>=20
>> At least a section within a home architecture document.
>>=20
>>> * A recommendation for a specific routing protocol ?
>=20
> [JW] I see a guidelines/analysis for link-state vs. distance-vector
> routing protocols in a multi-segment home network as being useful.

In my opinion, operation without active admin intervention is more =
important than the particular technology. =20

- Ralph

>=20
>>=20
>>> * A framework before the specification of a new routing protocol ?
>=20
> [JW] A framework or justification statement for a new lightweight =
routing
> protocol would be useful as well. A source/dest aware protocol has =
been
> proposed as a possible solution for the multi-homed home network for
> example.
>=20
>>=20
>> The charter says:
>>=20
>> "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."
>>=20
>> - Mark
>>=20
>>=20
>>> I'm clearly not expressing an opinion, just a question.
>>> Thanks.
>>> JP.
>>>=20
>>> JP Vasseur
>>> Cisco Fellow
>>>=20
>>> Sent from Blackberry
>>>=20
>>> ----- Original Message -----
>>> From: Mark Townsley [mailto:mark@townsley.net]
>>> Sent: Thursday, June 30, 2011 11:36 AM
>>> To: Weil, Jason <jason.weil@twcable.com>
>>> Cc: fun@ietf.org <fun@ietf.org>; homegate@ietf.org =
<homegate@ietf.org>
>>> Subject: Re: [fun] status of the homenet effort
>>>=20
>>>=20
>>> Thank you for the feedback, keep it coming.
>>>=20
>>> On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote:
>>>=20
>>>> Mark, Raplh, Jari, et all,
>>>>=20
>>>> I really appreciate the change in charter and direction for this
>>>> proposed
>>>> WG and the interest to keep it going. I believe it sets a path that =
is
>>>> scoped narrow enough to provide a workplace for achievable results.
>>>>=20
>>>> As a provider working on writing, testing and implementing IPv6 =
CPE, I
>>>> can
>>>> relate firsthand that getting basic IPv6 functionality working in =
the
>>>> home
>>>> network is no simple feat and is still a work in progress. Don't =
get me
>>>> wrong, basic functionality is there just not baked. What seems very
>>>> straightforward in theory typically fails in a multitude of corner
>>>> cases
>>>> ie reality. And just to clarify I am referring to a single /64 =
subnet
>>>> topology with no routing.
>>>>=20
>>>> If we can stay focussed on solving just the basics for the five =
areas
>>>> included, I believe it will be helpful. The other recommendation =
would
>>>> be
>>>> to work as expeditiously as possible. Providers in the process of
>>>> deploying IPv6 now are already deep into this analysis and =
development
>>>> with their vendors. If we wait too long then these topics will be
>>>> solved
>>>> with interoperability a possible casualty.
>>>>=20
>>>> FWIW, I would also add that the five topics in the charter are also
>>>> listed
>>>> in order
>>>> Of priority at least for me.
>>>>=20
>>>>=20
>>>> Thanks,
>>>>=20
>>>> Jason
>>>>=20
>>>>=20
>>>> On 6/29/11 5:46 AM, "Mark Townsley" <mark@townsley.net> wrote:
>>>>=20
>>>>>=20
>>>>> All,
>>>>>=20
>>>>> Apologies for double-posting if there are folks that are =
subscribed to
>>>>> homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone =
will
>>>>> finally create homenet@ietf.org and consolidate the membership
>>>>> accordingly.
>>>>>=20
>>>>> In the charter proposal below, I think you will see a lot of
>>>>> similarity
>>>>> with the consensus we achieved on the homegate list last year. =
Jari
>>>>> has
>>>>> taken that, feedback from the IESG, IAB, members of the
>>>>> IP-Directorate,
>>>>> v6ops chairs, etc. and shaped it towards something more focused on =
the
>>>>> Internet (and Routing) area, as well as IPv6. I believe he and =
Ralph
>>>>> both
>>>>> have a great deal of confidence that this is something that is =
very
>>>>> important to the industry, and that the IETF has a critical role =
to
>>>>> play.
>>>>>=20
>>>>> So, make no mistake, whether we end up as a WG or a BoF between =
now
>>>>> and
>>>>> Quebec, "we're back" - please send comments, and make your travel =
or
>>>>> remote-attendance plans accordingly if you want to participate.
>>>>>=20
>>>>> Jari has asked me to co-chair the session in Quebec. As such, I'd
>>>>> like to
>>>>> take requests for presentation time now. Jari and I will likely =
begin
>>>>> the
>>>>> session with a scoping overview, as well as a first cut at an
>>>>> architecture framework, but there should be some time for a few =
other
>>>>> items. When submitting your request, please identify which of the =
5
>>>>> areas
>>>>> below you think your work applies to as well as the =
internet-draft, of
>>>>> course.
>>>>>=20
>>>>> Thanks, and see you on the list and in Quebec.
>>>>>=20
>>>>> - Mark
>>>>>=20
>>>>>=20
>>>>> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote:
>>>>>=20
>>>>>> I wanted to provide an update of the situation with this working
>>>>>> group
>>>>>> proposal.
>>>>>>=20
>>>>>> HOMENET is a new working group proposal, a variation of the
>>>>>> HOMEGATE/HOMENET theme that we discussed last year, but this time
>>>>>> looking at it from a different angle. The old effort was mostly
>>>>>> focused
>>>>>> about what home gateways should do: forwarding, transport, and =
DNS
>>>>>> proxying issues. The new effort is about home networks =
themselves, in
>>>>>> particular what kind of network architecture and configuration is
>>>>>> necessary to support IPv6-based home networks. We view IPv4-based
>>>>>> home
>>>>>> networks as "done" at this time (or perhaps as "cannot be changed
>>>>>> anyway").
>>>>>>=20
>>>>>> I have been discussing this effort in the background for the last
>>>>>> couple of month with Mark Townsley and others, and more publicly
>>>>>> since
>>>>>> early June. The proposal has been brought to the IESG, IAB and =
some
>>>>>> directorates for discussion, and we've been going back and forth
>>>>>> whether
>>>>>> this is ready to become a working group or needs to be run as a =
BOF
>>>>>> in
>>>>>> Quebec City. The current plan is that the working group proposal
>>>>>> goes to
>>>>>> IETF-wide review this week, and if the feedback from the =
community,
>>>>>> IAB,
>>>>>> and the IESG is positive, we will create the working group just =
in
>>>>>> time
>>>>>> for the IETF. Otherwise, the slot reserved in the agenda for the
>>>>>> meeting
>>>>>> will be used to run the proposal as a BOF.
>>>>>>=20
>>>>>> In any case, I would like to solicit discussion on this topic, =
and
>>>>>> perhaps some early drafts as well. Please comment on the charter =
at
>>>>>> least.
>>>>>>=20
>>>>>> Note that the new proposal was called FUN at the time that we =
created
>>>>>> the list. It has now been renamed back to HOMENET to be more
>>>>>> descriptive. The list will be renamed soon as well (current
>>>>>> subscribers
>>>>>> will stay).
>>>>>>=20
>>>>>> This is the most recent version of the charter we should discuss:
>>>>>>=20
>>>>>> Home Networks (homenet)
>>>>>> -----------------------------------
>>>>>>=20
>>>>>> Current Status: Proposed
>>>>>> Last Edit: Wednesday, June 29th, 2011
>>>>>>=20
>>>>>> Chairs:
>>>>>> TBD
>>>>>>=20
>>>>>> Internet Area Directors:
>>>>>> Ralph Droms <rdroms.ietf@gmail.com>
>>>>>> Jari Arkko <jari.arkko@piuha.net>
>>>>>>=20
>>>>>> Internet Area Advisor:
>>>>>> Jari Arkko <jari.arkko@piuha.net>
>>>>>>=20
>>>>>> Routing Area Technical Advisor:
>>>>>> TBD
>>>>>>=20
>>>>>> Security Area Technical Advisor:
>>>>>> TBD
>>>>>>=20
>>>>>> 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
>>>>>>=20
>>>>>> Description of Working Group:
>>>>>>=20
>>>>>> This working group focuses on the evolving networking technology
>>>>>> within and among relatively small =B3residential home=B2 =
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:
>>>>>>=20
>>>>>> 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. Different segments may be associated =
with
>>>>>> subnets that have different routing and security policies.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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. 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:
>>>>>>=20
>>>>>> o prefix configuration for routers
>>>>>> o managing routing
>>>>>> o name resolution
>>>>>> o service discovery
>>>>>> o network security
>>>>>>=20
>>>>>> 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. 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 one 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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 liase 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.
>>>>>>=20
>>>>>> Milestones:
>>>>>>=20
>>>>>> 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
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> fun mailing list
>>>>>> fun@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/fun
>>>>>=20
>>>>> _______________________________________________
>>>>> fun mailing list
>>>>> fun@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/fun
>>>>=20
>>>>=20
>>>> This E-mail and any of its attachments may contain Time Warner =
Cable
>>>> proprietary information, which is privileged, confidential, or =
subject
>>>> to copyright belonging to Time Warner Cable. This E-mail is =
intended
>>>> solely for the use of the individual or entity to which it is
>>>> addressed. If you are not the intended recipient of this E-mail, =
you
>>>> are hereby notified that any dissemination, distribution, copying, =
or
>>>> action taken in relation to the contents of and attachments to this
>>>> E-mail is strictly prohibited and may be unlawful. If you have =
received
>>>> this E-mail in error, please notify the sender immediately and
>>>> permanently delete the original and any copy of this E-mail and any
>>>> printout.
>>>=20
>>> _______________________________________________
>>> fun mailing list
>>> fun@ietf.org
>>> https://www.ietf.org/mailman/listinfo/fun
>>=20
>=20
>=20
> This E-mail and any of its attachments may contain Time Warner Cable =
proprietary information, which is privileged, confidential, or subject =
to copyright belonging to Time Warner Cable. This E-mail is intended =
solely for the use of the individual or entity to which it is addressed. =
If you are not the intended recipient of this E-mail, you are hereby =
notified that any dissemination, distribution, copying, or action taken =
in relation to the contents of and attachments to this E-mail is =
strictly prohibited and may be unlawful. If you have received this =
E-mail in error, please notify the sender immediately and permanently =
delete the original and any copy of this E-mail and any printout.
> _______________________________________________
> homegate mailing list
> homegate@ietf.org
> https://www.ietf.org/mailman/listinfo/homegate


From jvasseur@cisco.com  Fri Jul  1 08:01:36 2011
Return-Path: <jvasseur@cisco.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 59F179E8018; Fri,  1 Jul 2011 08:01:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.149
X-Spam-Level: 
X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
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 63yujp9OgNH1; Fri,  1 Jul 2011 08:01:34 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 649B99E8008; Fri,  1 Jul 2011 08:01:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jvasseur@cisco.com; l=19588; q=dns/txt; s=iport; t=1309532494; x=1310742094; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:from:to:cc; bh=rxQkMYvWsW4+Ngf6YLfOKiEuBALtpp9ARQrUpKBo9tw=; b=WQghVXBoavftytTXdrT7cum/Lkn4Dy7nNr7VuMj/5QqFxpB6KBKWOjIA A88GYOewzc/C/ZjTfijPwQd1s+gpyDmEyucNiHk0/fp/tGew3fjiZvWxl 9Ta55HnUu6Jend647+uJnoUVJ1TrsGmTxWdN1d2c68mx2/c5OBzOoxOn/ A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIBABjhDU6tJXG8/2dsb2JhbABEDpgujzV3iHmhdZ4Bgx8TgwAEhz6Pc4RHhwk
X-IronPort-AV: E=Sophos;i="4.65,458,1304294400"; d="scan'208";a="390088336"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 01 Jul 2011 15:01:31 +0000
Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p61F1Van022975;  Fri, 1 Jul 2011 15:01:31 GMT
Received: from xmb-rcd-203.cisco.com ([72.163.62.210]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 1 Jul 2011 10:01:31 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 1 Jul 2011 10:01:30 -0500
Message-ID: <E104C094D4487643BB93F43875CBCBCF032BD3DA@XMB-RCD-203.cisco.com>
In-Reply-To: <9F9A2F4E-54D4-47EB-B57D-041BB56F9523@cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [homegate] [fun] status of the homenet effort
Thread-Index: Acw3/HFBeThPmlw3Txed3gx0hkraNQAA1FLP
From: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
To: "Ralph Droms (rdroms)" <rdroms@cisco.com>, <jason.weil@twcable.com>
X-OriginalArrivalTime: 01 Jul 2011 15:01:31.0096 (UTC) FILETIME=[C2C7BD80:01CC37FF]
X-Mailman-Approved-At: Fri, 01 Jul 2011 08:11:01 -0700
Cc: fun@ietf.org, homegate@ietf.org
Subject: Re: [homegate] [fun] status of the homenet effort
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: Fri, 01 Jul 2011 15:01:36 -0000

Agreeing with Ralph.

JP Vasseur
Cisco Fellow

Sent from Blackberry

----- Original Message -----
From: Ralph Droms (rdroms)
Sent: Friday, July 01, 2011 09:37 AM
To: Weil, Jason <jason.weil@twcable.com>
Cc: Mark Townsley <mark@townsley.net>; JP Vasseur (jvasseur); =
fun@ietf.org <fun@ietf.org>; homegate@ietf.org <homegate@ietf.org>
Subject: Re: [homegate] [fun] status of the homenet effort


On Jul 1, 2011, at 9:32 AM 7/1/11, Weil, Jason wrote:

>=20
>=20
> On 7/1/11 4:06 AM, "Mark Townsley" <mark@townsley.net> wrote:
>=20
>>=20
>> On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote:
>>=20
>>> I also think that this deals with an important topic and the list of
>>> items listed on the proposed charter are quite relevant. I'm just =
not
>>> entirely clear on the "routing component": are you referring to:
>>> * A requirement document for Routing in the home?
>>=20
>> At least a section within a home architecture document.
>>=20
>>> * A recommendation for a specific routing protocol ?
>=20
> [JW] I see a guidelines/analysis for link-state vs. distance-vector
> routing protocols in a multi-segment home network as being useful.

In my opinion, operation without active admin intervention is more =
important than the particular technology. =20

>>> * A framework before the specification of a new routing protocol ?
>=20
> [JW] A framework or justification statement for a new lightweight =
routing
> protocol would be useful as well. A source/dest aware protocol has =
been
> proposed as a possible solution for the multi-homed home network for
> example.

>> The charter says:
>>=20
>> "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."

Source/dest aware protocol sounds more like a research project.  =
Developing requirements might be in scope for homenet.

- Ralph

>>=20
>> - Mark
>>=20
>>=20
>>> I'm clearly not expressing an opinion, just a question.
>>> Thanks.
>>> JP.
>>>=20
>>> JP Vasseur
>>> Cisco Fellow
>>>=20
>>> Sent from Blackberry
>>>=20
>>> ----- Original Message -----
>>> From: Mark Townsley [mailto:mark@townsley.net]
>>> Sent: Thursday, June 30, 2011 11:36 AM
>>> To: Weil, Jason <jason.weil@twcable.com>
>>> Cc: fun@ietf.org <fun@ietf.org>; homegate@ietf.org =
<homegate@ietf.org>
>>> Subject: Re: [fun] status of the homenet effort
>>>=20
>>>=20
>>> Thank you for the feedback, keep it coming.
>>>=20
>>> On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote:
>>>=20
>>>> Mark, Raplh, Jari, et all,
>>>>=20
>>>> I really appreciate the change in charter and direction for this
>>>> proposed
>>>> WG and the interest to keep it going. I believe it sets a path that =
is
>>>> scoped narrow enough to provide a workplace for achievable results.
>>>>=20
>>>> As a provider working on writing, testing and implementing IPv6 =
CPE, I
>>>> can
>>>> relate firsthand that getting basic IPv6 functionality working in =
the
>>>> home
>>>> network is no simple feat and is still a work in progress. Don't =
get me
>>>> wrong, basic functionality is there just not baked. What seems very
>>>> straightforward in theory typically fails in a multitude of corner
>>>> cases
>>>> ie reality. And just to clarify I am referring to a single /64 =
subnet
>>>> topology with no routing.
>>>>=20
>>>> If we can stay focussed on solving just the basics for the five =
areas
>>>> included, I believe it will be helpful. The other recommendation =
would
>>>> be
>>>> to work as expeditiously as possible. Providers in the process of
>>>> deploying IPv6 now are already deep into this analysis and =
development
>>>> with their vendors. If we wait too long then these topics will be
>>>> solved
>>>> with interoperability a possible casualty.
>>>>=20
>>>> FWIW, I would also add that the five topics in the charter are also
>>>> listed
>>>> in order
>>>> Of priority at least for me.
>>>>=20
>>>>=20
>>>> Thanks,
>>>>=20
>>>> Jason
>>>>=20
>>>>=20
>>>> On 6/29/11 5:46 AM, "Mark Townsley" <mark@townsley.net> wrote:
>>>>=20
>>>>>=20
>>>>> All,
>>>>>=20
>>>>> Apologies for double-posting if there are folks that are =
subscribed to
>>>>> homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone =
will
>>>>> finally create homenet@ietf.org and consolidate the membership
>>>>> accordingly.
>>>>>=20
>>>>> In the charter proposal below, I think you will see a lot of
>>>>> similarity
>>>>> with the consensus we achieved on the homegate list last year. =
Jari
>>>>> has
>>>>> taken that, feedback from the IESG, IAB, members of the
>>>>> IP-Directorate,
>>>>> v6ops chairs, etc. and shaped it towards something more focused on =
the
>>>>> Internet (and Routing) area, as well as IPv6. I believe he and =
Ralph
>>>>> both
>>>>> have a great deal of confidence that this is something that is =
very
>>>>> important to the industry, and that the IETF has a critical role =
to
>>>>> play.
>>>>>=20
>>>>> So, make no mistake, whether we end up as a WG or a BoF between =
now
>>>>> and
>>>>> Quebec, "we're back" - please send comments, and make your travel =
or
>>>>> remote-attendance plans accordingly if you want to participate.
>>>>>=20
>>>>> Jari has asked me to co-chair the session in Quebec. As such, I'd
>>>>> like to
>>>>> take requests for presentation time now. Jari and I will likely =
begin
>>>>> the
>>>>> session with a scoping overview, as well as a first cut at an
>>>>> architecture framework, but there should be some time for a few =
other
>>>>> items. When submitting your request, please identify which of the =
5
>>>>> areas
>>>>> below you think your work applies to as well as the =
internet-draft, of
>>>>> course.
>>>>>=20
>>>>> Thanks, and see you on the list and in Quebec.
>>>>>=20
>>>>> - Mark
>>>>>=20
>>>>>=20
>>>>> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote:
>>>>>=20
>>>>>> I wanted to provide an update of the situation with this working
>>>>>> group
>>>>>> proposal.
>>>>>>=20
>>>>>> HOMENET is a new working group proposal, a variation of the
>>>>>> HOMEGATE/HOMENET theme that we discussed last year, but this time
>>>>>> looking at it from a different angle. The old effort was mostly
>>>>>> focused
>>>>>> about what home gateways should do: forwarding, transport, and =
DNS
>>>>>> proxying issues. The new effort is about home networks =
themselves, in
>>>>>> particular what kind of network architecture and configuration is
>>>>>> necessary to support IPv6-based home networks. We view IPv4-based
>>>>>> home
>>>>>> networks as "done" at this time (or perhaps as "cannot be changed
>>>>>> anyway").
>>>>>>=20
>>>>>> I have been discussing this effort in the background for the last
>>>>>> couple of month with Mark Townsley and others, and more publicly
>>>>>> since
>>>>>> early June. The proposal has been brought to the IESG, IAB and =
some
>>>>>> directorates for discussion, and we've been going back and forth
>>>>>> whether
>>>>>> this is ready to become a working group or needs to be run as a =
BOF
>>>>>> in
>>>>>> Quebec City. The current plan is that the working group proposal
>>>>>> goes to
>>>>>> IETF-wide review this week, and if the feedback from the =
community,
>>>>>> IAB,
>>>>>> and the IESG is positive, we will create the working group just =
in
>>>>>> time
>>>>>> for the IETF. Otherwise, the slot reserved in the agenda for the
>>>>>> meeting
>>>>>> will be used to run the proposal as a BOF.
>>>>>>=20
>>>>>> In any case, I would like to solicit discussion on this topic, =
and
>>>>>> perhaps some early drafts as well. Please comment on the charter =
at
>>>>>> least.
>>>>>>=20
>>>>>> Note that the new proposal was called FUN at the time that we =
created
>>>>>> the list. It has now been renamed back to HOMENET to be more
>>>>>> descriptive. The list will be renamed soon as well (current
>>>>>> subscribers
>>>>>> will stay).
>>>>>>=20
>>>>>> This is the most recent version of the charter we should discuss:
>>>>>>=20
>>>>>> Home Networks (homenet)
>>>>>> -----------------------------------
>>>>>>=20
>>>>>> Current Status: Proposed
>>>>>> Last Edit: Wednesday, June 29th, 2011
>>>>>>=20
>>>>>> Chairs:
>>>>>> TBD
>>>>>>=20
>>>>>> Internet Area Directors:
>>>>>> Ralph Droms <rdroms.ietf@gmail.com>
>>>>>> Jari Arkko <jari.arkko@piuha.net>
>>>>>>=20
>>>>>> Internet Area Advisor:
>>>>>> Jari Arkko <jari.arkko@piuha.net>
>>>>>>=20
>>>>>> Routing Area Technical Advisor:
>>>>>> TBD
>>>>>>=20
>>>>>> Security Area Technical Advisor:
>>>>>> TBD
>>>>>>=20
>>>>>> 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
>>>>>>=20
>>>>>> Description of Working Group:
>>>>>>=20
>>>>>> This working group focuses on the evolving networking technology
>>>>>> within and among relatively small =B3residential home=B2 =
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:
>>>>>>=20
>>>>>> 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. Different segments may be associated =
with
>>>>>> subnets that have different routing and security policies.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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. 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:
>>>>>>=20
>>>>>> o prefix configuration for routers
>>>>>> o managing routing
>>>>>> o name resolution
>>>>>> o service discovery
>>>>>> o network security
>>>>>>=20
>>>>>> 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. 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 one 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> 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 liase 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.
>>>>>>=20
>>>>>> Milestones:
>>>>>>=20
>>>>>> 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
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> fun mailing list
>>>>>> fun@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/fun
>>>>>=20
>>>>> _______________________________________________
>>>>> fun mailing list
>>>>> fun@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/fun
>>>>=20
>>>>=20
>>>> This E-mail and any of its attachments may contain Time Warner =
Cable
>>>> proprietary information, which is privileged, confidential, or =
subject
>>>> to copyright belonging to Time Warner Cable. This E-mail is =
intended
>>>> solely for the use of the individual or entity to which it is
>>>> addressed. If you are not the intended recipient of this E-mail, =
you
>>>> are hereby notified that any dissemination, distribution, copying, =
or
>>>> action taken in relation to the contents of and attachments to this
>>>> E-mail is strictly prohibited and may be unlawful. If you have =
received
>>>> this E-mail in error, please notify the sender immediately and
>>>> permanently delete the original and any copy of this E-mail and any
>>>> printout.
>>>=20
>>> _______________________________________________
>>> fun mailing list
>>> fun@ietf.org
>>> https://www.ietf.org/mailman/listinfo/fun
>>=20
>=20
>=20
> This E-mail and any of its attachments may contain Time Warner Cable =
proprietary information, which is privileged, confidential, or subject =
to copyright belonging to Time Warner Cable. This E-mail is intended =
solely for the use of the individual or entity to which it is addressed. =
If you are not the intended recipient of this E-mail, you are hereby =
notified that any dissemination, distribution, copying, or action taken =
in relation to the contents of and attachments to this E-mail is =
strictly prohibited and may be unlawful. If you have received this =
E-mail in error, please notify the sender immediately and permanently =
delete the original and any copy of this E-mail and any printout.
> _______________________________________________
> homegate mailing list
> homegate@ietf.org
> https://www.ietf.org/mailman/listinfo/homegate


From jason.weil@twcable.com  Fri Jul  1 08:06:53 2011
Return-Path: <jason.weil@twcable.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 3BD0E9E8009; Fri,  1 Jul 2011 08:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.329
X-Spam-Level: 
X-Spam-Status: No, score=0.329 tagged_above=-999 required=5 tests=[AWL=0.192,  BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6]
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 hxYdDXNZ3654; Fri,  1 Jul 2011 08:06:51 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8019E8005; Fri,  1 Jul 2011 08:06:51 -0700 (PDT)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.65,458,1304308800"; d="scan'208";a="230905511"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 01 Jul 2011 11:06:04 -0400
Received: from PRVPEXVS04.corp.twcable.com ([10.136.163.28]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Fri, 1 Jul 2011 11:06:50 -0400
From: "Weil, Jason" <jason.weil@twcable.com>
To: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>, "Ralph Droms (rdroms)" <rdroms@cisco.com>
Date: Fri, 1 Jul 2011 11:06:49 -0400
Thread-Topic: [homegate] [fun] status of the homenet effort
Thread-Index: Acw3/HFBeThPmlw3Txed3gx0hkraNQAA1FLPAAAGRSA=
Message-ID: <34E4F50CAFA10349A41E0756550084FB0A909F58@PRVPEXVS04.corp.twcable.com>
References: <9F9A2F4E-54D4-47EB-B57D-041BB56F9523@cisco.com> <E104C094D4487643BB93F43875CBCBCF032BD3DA@XMB-RCD-203.cisco.com>
In-Reply-To: <E104C094D4487643BB93F43875CBCBCF032BD3DA@XMB-RCD-203.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 01 Jul 2011 08:11:01 -0700
Cc: "fun@ietf.org" <fun@ietf.org>, "homegate@ietf.org" <homegate@ietf.org>
Subject: Re: [homegate] [fun] status of the homenet effort
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: Fri, 01 Jul 2011 15:06:53 -0000

Agreed. My thought was Homenet builds consensus on what work is needed and =
possibly sets the requirements. The development work should occur in whatev=
er group is responsible for that technology.

Jason

-----Original Message-----
From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
Sent: Friday, July 01, 2011 11:02 AM
To: Ralph Droms (rdroms); Weil, Jason
Cc: mark@townsley.net; fun@ietf.org; homegate@ietf.org
Subject: Re: [homegate] [fun] status of the homenet effort

Agreeing with Ralph.

JP Vasseur
Cisco Fellow

Sent from Blackberry

----- Original Message -----
From: Ralph Droms (rdroms)
Sent: Friday, July 01, 2011 09:37 AM
To: Weil, Jason <jason.weil@twcable.com>
Cc: Mark Townsley <mark@townsley.net>; JP Vasseur (jvasseur); fun@ietf.org =
<fun@ietf.org>; homegate@ietf.org <homegate@ietf.org>
Subject: Re: [homegate] [fun] status of the homenet effort


On Jul 1, 2011, at 9:32 AM 7/1/11, Weil, Jason wrote:

>
>
> On 7/1/11 4:06 AM, "Mark Townsley" <mark@townsley.net> wrote:
>
>>
>> On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote:
>>
>>> I also think that this deals with an important topic and the list of
>>> items listed on the proposed charter are quite relevant. I'm just not
>>> entirely clear on the "routing component": are you referring to:
>>> * A requirement document for Routing in the home?
>>
>> At least a section within a home architecture document.
>>
>>> * A recommendation for a specific routing protocol ?
>
> [JW] I see a guidelines/analysis for link-state vs. distance-vector
> routing protocols in a multi-segment home network as being useful.

In my opinion, operation without active admin intervention is more importan=
t than the particular technology.

>>> * A framework before the specification of a new routing protocol ?
>
> [JW] A framework or justification statement for a new lightweight routing
> protocol would be useful as well. A source/dest aware protocol has been
> proposed as a possible solution for the multi-homed home network for
> example.

>> The charter says:
>>
>> "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."

Source/dest aware protocol sounds more like a research project.  Developing=
 requirements might be in scope for homenet.

- Ralph

>>
>> - Mark
>>
>>
>>> I'm clearly not expressing an opinion, just a question.
>>> Thanks.
>>> JP.
>>>
>>> JP Vasseur
>>> Cisco Fellow
>>>
>>> Sent from Blackberry
>>>
>>> ----- Original Message -----
>>> From: Mark Townsley [mailto:mark@townsley.net]
>>> Sent: Thursday, June 30, 2011 11:36 AM
>>> To: Weil, Jason <jason.weil@twcable.com>
>>> Cc: fun@ietf.org <fun@ietf.org>; homegate@ietf.org <homegate@ietf.org>
>>> Subject: Re: [fun] status of the homenet effort
>>>
>>>
>>> Thank you for the feedback, keep it coming.
>>>
>>> On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote:
>>>
>>>> Mark, Raplh, Jari, et all,
>>>>
>>>> I really appreciate the change in charter and direction for this
>>>> proposed
>>>> WG and the interest to keep it going. I believe it sets a path that is
>>>> scoped narrow enough to provide a workplace for achievable results.
>>>>
>>>> As a provider working on writing, testing and implementing IPv6 CPE, I
>>>> can
>>>> relate firsthand that getting basic IPv6 functionality working in the
>>>> home
>>>> network is no simple feat and is still a work in progress. Don't get m=
e
>>>> wrong, basic functionality is there just not baked. What seems very
>>>> straightforward in theory typically fails in a multitude of corner
>>>> cases
>>>> ie reality. And just to clarify I am referring to a single /64 subnet
>>>> topology with no routing.
>>>>
>>>> If we can stay focussed on solving just the basics for the five areas
>>>> included, I believe it will be helpful. The other recommendation would
>>>> be
>>>> to work as expeditiously as possible. Providers in the process of
>>>> deploying IPv6 now are already deep into this analysis and development
>>>> with their vendors. If we wait too long then these topics will be
>>>> solved
>>>> with interoperability a possible casualty.
>>>>
>>>> FWIW, I would also add that the five topics in the charter are also
>>>> listed
>>>> in order
>>>> Of priority at least for me.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>>
>>>> On 6/29/11 5:46 AM, "Mark Townsley" <mark@townsley.net> wrote:
>>>>
>>>>>
>>>>> All,
>>>>>
>>>>> Apologies for double-posting if there are folks that are subscribed t=
o
>>>>> homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone will
>>>>> finally create homenet@ietf.org and consolidate the membership
>>>>> accordingly.
>>>>>
>>>>> In the charter proposal below, I think you will see a lot of
>>>>> similarity
>>>>> with the consensus we achieved on the homegate list last year. Jari
>>>>> has
>>>>> taken that, feedback from the IESG, IAB, members of the
>>>>> IP-Directorate,
>>>>> v6ops chairs, etc. and shaped it towards something more focused on th=
e
>>>>> Internet (and Routing) area, as well as IPv6. I believe he and Ralph
>>>>> both
>>>>> have a great deal of confidence that this is something that is very
>>>>> important to the industry, and that the IETF has a critical role to
>>>>> play.
>>>>>
>>>>> So, make no mistake, whether we end up as a WG or a BoF between now
>>>>> and
>>>>> Quebec, "we're back" - please send comments, and make your travel or
>>>>> remote-attendance plans accordingly if you want to participate.
>>>>>
>>>>> Jari has asked me to co-chair the session in Quebec. As such, I'd
>>>>> like to
>>>>> take requests for presentation time now. Jari and I will likely begin
>>>>> the
>>>>> session with a scoping overview, as well as a first cut at an
>>>>> architecture framework, but there should be some time for a few other
>>>>> items. When submitting your request, please identify which of the 5
>>>>> areas
>>>>> below you think your work applies to as well as the internet-draft, o=
f
>>>>> course.
>>>>>
>>>>> Thanks, and see you on the list and in Quebec.
>>>>>
>>>>> - Mark
>>>>>
>>>>>
>>>>> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote:
>>>>>
>>>>>> I wanted to provide an update of the situation with this working
>>>>>> group
>>>>>> proposal.
>>>>>>
>>>>>> HOMENET is a new working group proposal, a variation of the
>>>>>> HOMEGATE/HOMENET theme that we discussed last year, but this time
>>>>>> looking at it from a different angle. The old effort was mostly
>>>>>> focused
>>>>>> about what home gateways should do: forwarding, transport, and DNS
>>>>>> proxying issues. The new effort is about home networks themselves, i=
n
>>>>>> particular what kind of network architecture and configuration is
>>>>>> necessary to support IPv6-based home networks. We view IPv4-based
>>>>>> home
>>>>>> networks as "done" at this time (or perhaps as "cannot be changed
>>>>>> anyway").
>>>>>>
>>>>>> I have been discussing this effort in the background for the last
>>>>>> couple of month with Mark Townsley and others, and more publicly
>>>>>> since
>>>>>> early June. The proposal has been brought to the IESG, IAB and some
>>>>>> directorates for discussion, and we've been going back and forth
>>>>>> whether
>>>>>> this is ready to become a working group or needs to be run as a BOF
>>>>>> in
>>>>>> Quebec City. The current plan is that the working group proposal
>>>>>> goes to
>>>>>> IETF-wide review this week, and if the feedback from the community,
>>>>>> IAB,
>>>>>> and the IESG is positive, we will create the working group just in
>>>>>> time
>>>>>> for the IETF. Otherwise, the slot reserved in the agenda for the
>>>>>> meeting
>>>>>> will be used to run the proposal as a BOF.
>>>>>>
>>>>>> In any case, I would like to solicit discussion on this topic, and
>>>>>> perhaps some early drafts as well. Please comment on the charter at
>>>>>> least.
>>>>>>
>>>>>> Note that the new proposal was called FUN at the time that we create=
d
>>>>>> the list. It has now been renamed back to HOMENET to be more
>>>>>> descriptive. The list will be renamed soon as well (current
>>>>>> subscribers
>>>>>> will stay).
>>>>>>
>>>>>> This is the most recent version of the charter we should discuss:
>>>>>>
>>>>>> Home Networks (homenet)
>>>>>> -----------------------------------
>>>>>>
>>>>>> Current Status: Proposed
>>>>>> Last Edit: Wednesday, June 29th, 2011
>>>>>>
>>>>>> Chairs:
>>>>>> TBD
>>>>>>
>>>>>> Internet Area Directors:
>>>>>> Ralph Droms <rdroms.ietf@gmail.com>
>>>>>> Jari Arkko <jari.arkko@piuha.net>
>>>>>>
>>>>>> Internet Area Advisor:
>>>>>> Jari Arkko <jari.arkko@piuha.net>
>>>>>>
>>>>>> 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 =B3residential home=B2 networks. F=
or
>>>>>> 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 requirement=
s
>>>>>> on IETF protocols. Some of the relevant trends include:
>>>>>>
>>>>>> o Multiple segments: While less complex L3-toplogies involving as fe=
w
>>>>>> 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. 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 i=
t
>>>>>> 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 i=
n
>>>>>> a manner accessible to all users of home networks. Manual
>>>>>> configuration is rarely, if at all, possible. 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. 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 one 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 defin=
e
>>>>>> 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 impac=
t
>>>>>> on manageability. The main focus of the working group is home
>>>>>> networks, but the group's results may also find applications in othe=
r
>>>>>> small networks.
>>>>>>
>>>>>> 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 liase 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.
>>>>>>
>>>>>> 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 Informationa=
l
>>>>>> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> fun mailing list
>>>>>> fun@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/fun
>>>>>
>>>>> _______________________________________________
>>>>> fun mailing list
>>>>> fun@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/fun
>>>>
>>>>
>>>> This E-mail and any of its attachments may contain Time Warner Cable
>>>> proprietary information, which is privileged, confidential, or subject
>>>> to copyright belonging to Time Warner Cable. This E-mail is intended
>>>> solely for the use of the individual or entity to which it is
>>>> addressed. If you are not the intended recipient of this E-mail, you
>>>> are hereby notified that any dissemination, distribution, copying, or
>>>> action taken in relation to the contents of and attachments to this
>>>> E-mail is strictly prohibited and may be unlawful. If you have receive=
d
>>>> this E-mail in error, please notify the sender immediately and
>>>> permanently delete the original and any copy of this E-mail and any
>>>> printout.
>>>
>>> _______________________________________________
>>> fun mailing list
>>> fun@ietf.org
>>> https://www.ietf.org/mailman/listinfo/fun
>>
>
>
> This E-mail and any of its attachments may contain Time Warner Cable prop=
rietary information, which is privileged, confidential, or subject to copyr=
ight belonging to Time Warner Cable. This E-mail is intended solely for the=
 use of the individual or entity to which it is addressed. If you are not t=
he intended recipient of this E-mail, you are hereby notified that any diss=
emination, distribution, copying, or action taken in relation to the conten=
ts of and attachments to this E-mail is strictly prohibited and may be unla=
wful. If you have received this E-mail in error, please notify the sender i=
mmediately and permanently delete the original and any copy of this E-mail =
and any printout.
> _______________________________________________
> homegate mailing list
> homegate@ietf.org
> https://www.ietf.org/mailman/listinfo/homegate


From mark@townsley.net  Fri Jul  1 08:47:51 2011
Return-Path: <mark@townsley.net>
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 61D7611E80F5; Fri,  1 Jul 2011 08:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.149
X-Spam-Level: 
X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
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 YOuA+juzLNIw; Fri,  1 Jul 2011 08:47:49 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BAD7311E8121; Fri,  1 Jul 2011 08:47:44 -0700 (PDT)
Received: by wyj26 with SMTP id 26so2645793wyj.31 for <multiple recipients>; Fri, 01 Jul 2011 08:47:44 -0700 (PDT)
Received: by 10.227.196.209 with SMTP id eh17mr3096185wbb.92.1309535263768; Fri, 01 Jul 2011 08:47:43 -0700 (PDT)
Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fe4sm2438492wbb.45.2011.07.01.08.47.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 08:47:42 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Mark Townsley <mark@townsley.net>
In-Reply-To: <34E4F50CAFA10349A41E0756550084FB0A909F58@PRVPEXVS04.corp.twcable.com>
Date: Fri, 1 Jul 2011 17:47:39 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <EFA82AF7-DD9F-4E33-9280-B3150D728409@townsley.net>
References: <9F9A2F4E-54D4-47EB-B57D-041BB56F9523@cisco.com> <E104C094D4487643BB93F43875CBCBCF032BD3DA@XMB-RCD-203.cisco.com> <34E4F50CAFA10349A41E0756550084FB0A909F58@PRVPEXVS04.corp.twcable.com>
To: "Weil, Jason" <jason.weil@twcable.com>
X-Mailer: Apple Mail (2.1084)
Cc: "Ralph Droms \(rdroms\)" <rdroms@cisco.com>, "fun@ietf.org" <fun@ietf.org>, "homegate@ietf.org" <homegate@ietf.org>, "JP Vasseur \(jvasseur\)" <jvasseur@cisco.com>
Subject: Re: [homegate] [fun] status of the homenet effort
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: Fri, 01 Jul 2011 15:47:51 -0000

On Jul 1, 2011, at 5:06 PM, Weil, Jason wrote:

> Agreed. My thought was Homenet builds consensus on what work is needed =
and possibly sets the requirements. The development work should occur in =
whatever group is responsible for that technology.

I think homenet could set defaults (not far removed from requirements, =
and something that is imperative in a home network and less so in =
others). Also, depending on the protocol involved, there may or may not =
be a WG setup to do the work - for example, DHCP's modus operandi is =
that simple DHCP options are defined not in the DHC WG itself, but in =
the "parent technology" WG with review from DHC.=20

In any case, I think this is why Jari included a  review stage of the =
work to be done after we get through the architecture/framework... We'll =
know better then what work can be knocked out under a homenet banner, =
and what needs to be forked elsewhere.=20

- Mark

>=20
> Jason
>=20
> -----Original Message-----
> From: JP Vasseur (jvasseur) [mailto:jvasseur@cisco.com]
> Sent: Friday, July 01, 2011 11:02 AM
> To: Ralph Droms (rdroms); Weil, Jason
> Cc: mark@townsley.net; fun@ietf.org; homegate@ietf.org
> Subject: Re: [homegate] [fun] status of the homenet effort
>=20
> Agreeing with Ralph.
>=20
> JP Vasseur
> Cisco Fellow
>=20
> Sent from Blackberry
>=20
> ----- Original Message -----
> From: Ralph Droms (rdroms)
> Sent: Friday, July 01, 2011 09:37 AM
> To: Weil, Jason <jason.weil@twcable.com>
> Cc: Mark Townsley <mark@townsley.net>; JP Vasseur (jvasseur); =
fun@ietf.org <fun@ietf.org>; homegate@ietf.org <homegate@ietf.org>
> Subject: Re: [homegate] [fun] status of the homenet effort
>=20
>=20
> On Jul 1, 2011, at 9:32 AM 7/1/11, Weil, Jason wrote:
>=20
>>=20
>>=20
>> On 7/1/11 4:06 AM, "Mark Townsley" <mark@townsley.net> wrote:
>>=20
>>>=20
>>> On Jul 1, 2011, at 7:27 AM, JP Vasseur (jvasseur) wrote:
>>>=20
>>>> I also think that this deals with an important topic and the list =
of
>>>> items listed on the proposed charter are quite relevant. I'm just =
not
>>>> entirely clear on the "routing component": are you referring to:
>>>> * A requirement document for Routing in the home?
>>>=20
>>> At least a section within a home architecture document.
>>>=20
>>>> * A recommendation for a specific routing protocol ?
>>=20
>> [JW] I see a guidelines/analysis for link-state vs. distance-vector
>> routing protocols in a multi-segment home network as being useful.
>=20
> In my opinion, operation without active admin intervention is more =
important than the particular technology.
>=20
>>>> * A framework before the specification of a new routing protocol ?
>>=20
>> [JW] A framework or justification statement for a new lightweight =
routing
>> protocol would be useful as well. A source/dest aware protocol has =
been
>> proposed as a possible solution for the multi-homed home network for
>> example.
>=20
>>> The charter says:
>>>=20
>>> "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."
>=20
> Source/dest aware protocol sounds more like a research project.  =
Developing requirements might be in scope for homenet.
>=20
> - Ralph
>=20
>>>=20
>>> - Mark
>>>=20
>>>=20
>>>> I'm clearly not expressing an opinion, just a question.
>>>> Thanks.
>>>> JP.
>>>>=20
>>>> JP Vasseur
>>>> Cisco Fellow
>>>>=20
>>>> Sent from Blackberry
>>>>=20
>>>> ----- Original Message -----
>>>> From: Mark Townsley [mailto:mark@townsley.net]
>>>> Sent: Thursday, June 30, 2011 11:36 AM
>>>> To: Weil, Jason <jason.weil@twcable.com>
>>>> Cc: fun@ietf.org <fun@ietf.org>; homegate@ietf.org =
<homegate@ietf.org>
>>>> Subject: Re: [fun] status of the homenet effort
>>>>=20
>>>>=20
>>>> Thank you for the feedback, keep it coming.
>>>>=20
>>>> On Jun 30, 2011, at 4:14 PM, Weil, Jason wrote:
>>>>=20
>>>>> Mark, Raplh, Jari, et all,
>>>>>=20
>>>>> I really appreciate the change in charter and direction for this
>>>>> proposed
>>>>> WG and the interest to keep it going. I believe it sets a path =
that is
>>>>> scoped narrow enough to provide a workplace for achievable =
results.
>>>>>=20
>>>>> As a provider working on writing, testing and implementing IPv6 =
CPE, I
>>>>> can
>>>>> relate firsthand that getting basic IPv6 functionality working in =
the
>>>>> home
>>>>> network is no simple feat and is still a work in progress. Don't =
get me
>>>>> wrong, basic functionality is there just not baked. What seems =
very
>>>>> straightforward in theory typically fails in a multitude of corner
>>>>> cases
>>>>> ie reality. And just to clarify I am referring to a single /64 =
subnet
>>>>> topology with no routing.
>>>>>=20
>>>>> If we can stay focussed on solving just the basics for the five =
areas
>>>>> included, I believe it will be helpful. The other recommendation =
would
>>>>> be
>>>>> to work as expeditiously as possible. Providers in the process of
>>>>> deploying IPv6 now are already deep into this analysis and =
development
>>>>> with their vendors. If we wait too long then these topics will be
>>>>> solved
>>>>> with interoperability a possible casualty.
>>>>>=20
>>>>> FWIW, I would also add that the five topics in the charter are =
also
>>>>> listed
>>>>> in order
>>>>> Of priority at least for me.
>>>>>=20
>>>>>=20
>>>>> Thanks,
>>>>>=20
>>>>> Jason
>>>>>=20
>>>>>=20
>>>>> On 6/29/11 5:46 AM, "Mark Townsley" <mark@townsley.net> wrote:
>>>>>=20
>>>>>>=20
>>>>>> All,
>>>>>>=20
>>>>>> Apologies for double-posting if there are folks that are =
subscribed to
>>>>>> homegate@ietf.org and fun@ietf.org. I'm hoping soon that someone =
will
>>>>>> finally create homenet@ietf.org and consolidate the membership
>>>>>> accordingly.
>>>>>>=20
>>>>>> In the charter proposal below, I think you will see a lot of
>>>>>> similarity
>>>>>> with the consensus we achieved on the homegate list last year. =
Jari
>>>>>> has
>>>>>> taken that, feedback from the IESG, IAB, members of the
>>>>>> IP-Directorate,
>>>>>> v6ops chairs, etc. and shaped it towards something more focused =
on the
>>>>>> Internet (and Routing) area, as well as IPv6. I believe he and =
Ralph
>>>>>> both
>>>>>> have a great deal of confidence that this is something that is =
very
>>>>>> important to the industry, and that the IETF has a critical role =
to
>>>>>> play.
>>>>>>=20
>>>>>> So, make no mistake, whether we end up as a WG or a BoF between =
now
>>>>>> and
>>>>>> Quebec, "we're back" - please send comments, and make your travel =
or
>>>>>> remote-attendance plans accordingly if you want to participate.
>>>>>>=20
>>>>>> Jari has asked me to co-chair the session in Quebec. As such, I'd
>>>>>> like to
>>>>>> take requests for presentation time now. Jari and I will likely =
begin
>>>>>> the
>>>>>> session with a scoping overview, as well as a first cut at an
>>>>>> architecture framework, but there should be some time for a few =
other
>>>>>> items. When submitting your request, please identify which of the =
5
>>>>>> areas
>>>>>> below you think your work applies to as well as the =
internet-draft, of
>>>>>> course.
>>>>>>=20
>>>>>> Thanks, and see you on the list and in Quebec.
>>>>>>=20
>>>>>> - Mark
>>>>>>=20
>>>>>>=20
>>>>>> On Jun 29, 2011, at 10:35 AM, Jari Arkko wrote:
>>>>>>=20
>>>>>>> I wanted to provide an update of the situation with this working
>>>>>>> group
>>>>>>> proposal.
>>>>>>>=20
>>>>>>> HOMENET is a new working group proposal, a variation of the
>>>>>>> HOMEGATE/HOMENET theme that we discussed last year, but this =
time
>>>>>>> looking at it from a different angle. The old effort was mostly
>>>>>>> focused
>>>>>>> about what home gateways should do: forwarding, transport, and =
DNS
>>>>>>> proxying issues. The new effort is about home networks =
themselves, in
>>>>>>> particular what kind of network architecture and configuration =
is
>>>>>>> necessary to support IPv6-based home networks. We view =
IPv4-based
>>>>>>> home
>>>>>>> networks as "done" at this time (or perhaps as "cannot be =
changed
>>>>>>> anyway").
>>>>>>>=20
>>>>>>> I have been discussing this effort in the background for the =
last
>>>>>>> couple of month with Mark Townsley and others, and more publicly
>>>>>>> since
>>>>>>> early June. The proposal has been brought to the IESG, IAB and =
some
>>>>>>> directorates for discussion, and we've been going back and forth
>>>>>>> whether
>>>>>>> this is ready to become a working group or needs to be run as a =
BOF
>>>>>>> in
>>>>>>> Quebec City. The current plan is that the working group proposal
>>>>>>> goes to
>>>>>>> IETF-wide review this week, and if the feedback from the =
community,
>>>>>>> IAB,
>>>>>>> and the IESG is positive, we will create the working group just =
in
>>>>>>> time
>>>>>>> for the IETF. Otherwise, the slot reserved in the agenda for the
>>>>>>> meeting
>>>>>>> will be used to run the proposal as a BOF.
>>>>>>>=20
>>>>>>> In any case, I would like to solicit discussion on this topic, =
and
>>>>>>> perhaps some early drafts as well. Please comment on the charter =
at
>>>>>>> least.
>>>>>>>=20
>>>>>>> Note that the new proposal was called FUN at the time that we =
created
>>>>>>> the list. It has now been renamed back to HOMENET to be more
>>>>>>> descriptive. The list will be renamed soon as well (current
>>>>>>> subscribers
>>>>>>> will stay).
>>>>>>>=20
>>>>>>> This is the most recent version of the charter we should =
discuss:
>>>>>>>=20
>>>>>>> Home Networks (homenet)
>>>>>>> -----------------------------------
>>>>>>>=20
>>>>>>> Current Status: Proposed
>>>>>>> Last Edit: Wednesday, June 29th, 2011
>>>>>>>=20
>>>>>>> Chairs:
>>>>>>> TBD
>>>>>>>=20
>>>>>>> Internet Area Directors:
>>>>>>> Ralph Droms <rdroms.ietf@gmail.com>
>>>>>>> Jari Arkko <jari.arkko@piuha.net>
>>>>>>>=20
>>>>>>> Internet Area Advisor:
>>>>>>> Jari Arkko <jari.arkko@piuha.net>
>>>>>>>=20
>>>>>>> Routing Area Technical Advisor:
>>>>>>> TBD
>>>>>>>=20
>>>>>>> Security Area Technical Advisor:
>>>>>>> TBD
>>>>>>>=20
>>>>>>> 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
>>>>>>>=20
>>>>>>> Description of Working Group:
>>>>>>>=20
>>>>>>> This working group focuses on the evolving networking technology
>>>>>>> within and among relatively small =B3residential home=B2 =
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:
>>>>>>>=20
>>>>>>> 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. Different segments may be associated =
with
>>>>>>> subnets that have different routing and security policies.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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. 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:
>>>>>>>=20
>>>>>>> o prefix configuration for routers
>>>>>>> o managing routing
>>>>>>> o name resolution
>>>>>>> o service discovery
>>>>>>> o network security
>>>>>>>=20
>>>>>>> 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. 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 one 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.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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 liase 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.
>>>>>>>=20
>>>>>>> Milestones:
>>>>>>>=20
>>>>>>> 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
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> fun mailing list
>>>>>>> fun@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/fun
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> fun mailing list
>>>>>> fun@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/fun
>>>>>=20
>>>>>=20
>>>>> This E-mail and any of its attachments may contain Time Warner =
Cable
>>>>> proprietary information, which is privileged, confidential, or =
subject
>>>>> to copyright belonging to Time Warner Cable. This E-mail is =
intended
>>>>> solely for the use of the individual or entity to which it is
>>>>> addressed. If you are not the intended recipient of this E-mail, =
you
>>>>> are hereby notified that any dissemination, distribution, copying, =
or
>>>>> action taken in relation to the contents of and attachments to =
this
>>>>> E-mail is strictly prohibited and may be unlawful. If you have =
received
>>>>> this E-mail in error, please notify the sender immediately and
>>>>> permanently delete the original and any copy of this E-mail and =
any
>>>>> printout.
>>>>=20
>>>> _______________________________________________
>>>> fun mailing list
>>>> fun@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/fun
>>>=20
>>=20
>>=20
>> This E-mail and any of its attachments may contain Time Warner Cable =
proprietary information, which is privileged, confidential, or subject =
to copyright belonging to Time Warner Cable. This E-mail is intended =
solely for the use of the individual or entity to which it is addressed. =
If you are not the intended recipient of this E-mail, you are hereby =
notified that any dissemination, distribution, copying, or action taken =
in relation to the contents of and attachments to this E-mail is =
strictly prohibited and may be unlawful. If you have received this =
E-mail in error, please notify the sender immediately and permanently =
delete the original and any copy of this E-mail and any printout.
>> _______________________________________________
>> homegate mailing list
>> homegate@ietf.org
>> https://www.ietf.org/mailman/listinfo/homegate
>=20


From jhw@apple.com  Fri Jul  1 09:39:19 2011
Return-Path: <jhw@apple.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 5994E1F0C82; Fri,  1 Jul 2011 09:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 dDMp0ULCXemp; Fri,  1 Jul 2011 09:39:18 -0700 (PDT)
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id E33371F0C60; Fri,  1 Jul 2011 09:39:18 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LNN00HLAY5LQE01@mail-out.apple.com>; Fri, 01 Jul 2011 09:37:46 -0700 (PDT)
X-AuditID: 11807130-b7c45ae000001381-02-4e0df7c0ab2c
Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate)	by relay11.apple.com (Apple SCV relay) with SMTP id 5B.19.04993.0C7FD0E4; Fri, 01 Jul 2011 09:37:20 -0700 (PDT)
Received: from [172.16.1.2] (adit.conjury.org [75.101.54.88]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNN00GIUY6YQK80@cardamom.apple.com>; Fri, 01 Jul 2011 09:37:46 -0700 (PDT)
From: james woodyatt <jhw@apple.com>
In-reply-to: <-4529087406481929693@unknownmsgid>
Date: Fri, 01 Jul 2011 09:37:46 -0700
Message-id: <9F80E933-D8C4-4579-960F-81230B16DD57@apple.com>
References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <alpine.DEB.2.00.1106300707370.19581@uplift.swm.pp.se> <4E0C1CF8.7090601@gont.com.ar> <alpine.DEB.2.00.1106300923280.19581@uplift.swm.pp.se> <558D0669-8B2A-4514-B3FB-C690C40A4EF8@townsley.net> <0F995E91-9853-4018-91F0-0699E1A7A06F@network-heretics.com> <780C3063-AD82-46F3-874A-C4E1E61EE508@townsley.net> <4E0D0281.3020608@raszuk.net> <B9E7B6AF-6BD0-4BD4-AEAC-D318C099CCCE@apple.com> <-4529087406481929693@unknownmsgid>
To: Martin Focazio <martyf@gmail.com>
X-Mailer: Apple Mail (2.1244.3)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUiON1OVffAd14/g5lNGhaPD8xit9h2qZ/N gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZ+xbsZSo4yF1xp6uXuYFxDWcXIyeHhICJxOdDk1kh bDGJC/fWs3UxcnEICbQySXw5u4IRJMErICjxY/I9li5GDg5mAXmJg+dlQcLMAloS3x+1skDU 9zFJHFnSwgSSEBawkZjU9QbMZhNQkfh2+S6YzSlgILF8/06wmSwCqhLPWpaxQAzykrj29hc7 xC4biYfT2sEOEhL4zSyxZosQiC0CVN+x/QwjxKHyEotbPjNOYBSYheS8WQjnzUJy3gJG5lWM gkWpOYmVhoZ6iQUFOal6yfm5mxhBIdhQaLCDce1P/kOMAhyMSjy8C57y+gmxJpYVV+YeYpTg YFYS4W29DhTiTUmsrEotyo8vKs1JLT7EKM3BoiTOG5vJ7SckkJ5YkpqdmlqQWgSTZeLglGpg dChjTmJXidr7eVpe/JszN50Ma9+WshZqXeLVPXnLSuLxsSl7td2VjmpZaTLo3+/Kjv3rVlZ6 Ys68KacvXNWcusLK+IE++0fO2FJP20l7r6d8fzuD68rfmNDDatISQZFaOxbf4XttcG7jg0OJ +1oWbkk8wMLy/eK1jm0WzDmrfyfWZUulvgt+rcRSnJFoqMVcVJwIAHW93589AgAA
Cc: "fun@ietf.org" <fun@ietf.org>, "homegate@ietf.org" <homegate@ietf.org>
Subject: Re: [homegate] [fun] HOMENET working group proposal
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: Fri, 01 Jul 2011 16:39:19 -0000

On Jun 30, 2011, at 6:34 PM, Martin Focazio wrote:
> On Jun 30, 2011, at 19:51, james woodyatt <jhw@apple.com> wrote:
>> 
>> The key thing here is that by Alice choosing to use one service provider over another, she can make Bob's application fail, and vice versa.  The mobile service providers that don't have enough IPv4 addresses to serve all their customers are in a bind and can't budge.  The wireline service providers who have 5-10 years of IPv4 addresses in reserve are the ones whistling past the graveyard.
> 
> You assume at Alice CAN select a service provider. In a large part of
> the USA your choices are nil. You have a single wireline provider or
> you don't have a connection.

Telecommunications services are still ostensibly a regulated utility in the USA.

If the people living in those areas neither want to move, nor demand their utility commissions to hold service providers accountable for the proper operation of the monopoly franchise they receive from the government, then those people are making their choice.  Choosing an alternative is possible.  It entails either individual action to relocate or collective action to reform the telecommunications services.  Inaction, of course, is also an alternative.  People choose one or the other.

As I said, Alice can break Bob's applications by choosing her service provider.  And vice versa.


--
james woodyatt <jhw@apple.com>
member of technical staff, core os networking




From rogerj@gmail.com  Fri Jul  8 00:46:03 2011
Return-Path: <rogerj@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 DA7BA21F8785; Fri,  8 Jul 2011 00:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 ZVw7mMVe2n-B; Fri,  8 Jul 2011 00:46:03 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB6DE21F8783; Fri,  8 Jul 2011 00:46:02 -0700 (PDT)
Received: by wwe5 with SMTP id 5so1121525wwe.13 for <multiple recipients>; Fri, 08 Jul 2011 00:46:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=10KdA6BB7YTziXhvMqyGI62wfRhWPh8GL5XxYDwUtnY=; b=uQh/OqMyQg0zYDHG/JBiMWUvHJLdiUJclSuVpMkuXYkKMhqNvIy5WqxUZEPGKphNJX tb3BNyVstVFgTkcLLPzTCyhmN6IFJV9rl00gNA+31DE/y7LsOeZv4EH27l4iV/3CFOBs dIZj8eAGAC/lVzrZpNlecqjYBfCN7hCiEfvwY=
MIME-Version: 1.0
Received: by 10.227.55.136 with SMTP id u8mr966304wbg.99.1310111161085; Fri, 08 Jul 2011 00:46:01 -0700 (PDT)
Received: by 10.227.142.137 with HTTP; Fri, 8 Jul 2011 00:46:00 -0700 (PDT)
In-Reply-To: <4E0BE5FF.3000409@gont.com.ar>
References: <4E0AE696.4020603@piuha.net> <4E0BDCF3.1090003@gont.com.ar> <BANLkTinuPcq2r85kzMctFCHDB3Ta=WgA4A@mail.gmail.com> <4E0BE5FF.3000409@gont.com.ar>
Date: Fri, 8 Jul 2011 09:46:00 +0200
Message-ID: <CAKFn1SF6yZK4wW==yK+7g+OzFnOFxGHT=FW-bXzYPOtxMWrF5g@mail.gmail.com>
From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= <rogerj@gmail.com>
To: Fernando Gont <fernando@gont.com.ar>, Cameron Byrne <cb.list6@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 08 Jul 2011 01:07:55 -0700
Cc: IETF Discussion <ietf@ietf.org>, "homegate@ietf.org" <homegate@ietf.org>
Subject: Re: [homegate] HOMENET working group proposal
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: Fri, 08 Jul 2011 07:46:04 -0000

On Thu, Jun 30, 2011 at 4:57 AM, Fernando Gont <fernando@gont.com.ar> wrote=
:
> On 06/29/2011 11:38 PM, Cameron Byrne wrote:
>
>> The opportunity for restoring e2e is one of the great opportunities of
>> ipv6
>
> This assumes that e2e reachability is a desired property for all networks=
.

A very good point, there are a few network that break e2e on purpose.
But I guess this mostly affect enterprises and not the general
Internet part, and still I would guess that the network on the
"inside" for those enterprises still use e2e quite heavily so it's
still relevant.



--=20

Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 |
rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key!
http://www.jorgensen.no=A0=A0 | roger@jorgensen.no

From carlberg@g11.org.uk  Tue Jul 12 06:11:14 2011
Return-Path: <carlberg@g11.org.uk>
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 95DC921F90C0 for <homegate@ietfa.amsl.com>; Tue, 12 Jul 2011 06:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.98
X-Spam-Level: 
X-Spam-Status: No, score=-0.98 tagged_above=-999 required=5 tests=[AWL=-0.981,  BAYES_50=0.001]
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 6FQEijwwfWby for <homegate@ietfa.amsl.com>; Tue, 12 Jul 2011 06:11:14 -0700 (PDT)
Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id EA19221F8B73 for <homegate@ietf.org>; Tue, 12 Jul 2011 06:11:13 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=KVyLjjDf7oIuDZxZQ6Fy2xNK1DLNumMpQu/4rm8bOxqtz4t9EMVn4z5TUnhiq8JihqWAUg8snreJ1iy13ScHP5OiaR18oBggYO+UzYQM60UdCInrmk/jnUyGH5TaERQe;
Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:61165 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from <carlberg@g11.org.uk>) id 1Qgcjx-0001gX-RM; Tue, 12 Jul 2011 13:11:05 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: ken carlberg <carlberg@g11.org.uk>
In-Reply-To: <4E0AE696.4020603@piuha.net>
Date: Tue, 12 Jul 2011 09:11:10 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7FC8F60B-469E-4635-B5C0-4FD6B9AC30F8@g11.org.uk>
References: <4E0AE696.4020603@piuha.net>
To: Jari Arkko <jari.arkko@piuha.net>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: homegate@ietf.org
Subject: Re: [homegate] HOMENET working group proposal
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: Tue, 12 Jul 2011 13:11:14 -0000

Jari,

My apologies for the tardy response, but given the following text in the =
proposed charter...

> 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. 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:
>=20
> o prefix configuration for routers
> o managing routing
> o name resolution
> o service discovery
> o network security

...I was wondering where something like buffer-bloat, and in particular =
supporting/managing AQM, would fit in given the above.  Jim Getty's talk =
at the last IETF meeting was well received and appeared to open some =
eyes to an issue that seemed to have been easily overseen.  My =
impression is that work in Home Networks could help address some of the =
items that Jim brought up in his presentation.

thoughts?

-ken
=20=

From fred@cisco.com  Tue Jul 12 07:04:21 2011
Return-Path: <fred@cisco.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 254E221F9164 for <homegate@ietfa.amsl.com>; Tue, 12 Jul 2011 07:04:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.942
X-Spam-Level: 
X-Spam-Status: No, score=-105.942 tagged_above=-999 required=5 tests=[AWL=-3.343, BAYES_00=-2.599, 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 ziTGCZKV9s77 for <homegate@ietfa.amsl.com>; Tue, 12 Jul 2011 07:04:20 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6E63E21F9165 for <homegate@ietf.org>; Tue, 12 Jul 2011 07:04:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1497; q=dns/txt; s=iport; t=1310479460; x=1311689060; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=6I846/EcNDQuG2wy815o5ACN5KvoEQOpKe3odfonvdw=; b=mvTQ6f+jMdz1YP1qIskxXSEuvbPUevTqps1Yya0gz2VvQqjPTNEx64+W Sm38LK5MhyJOX9HlbPompqxoSY/PLXqtvmOtpV65WjlYbFQ4Y/tDYbCDn kVTrVjppHpE2WbqkcqoS9bno3uOXrgI3iCP6lPL1vkt7KBiSA8KeIHVv/ s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAOdTHE6rRDoI/2dsb2JhbABTpy93rRWeGoVbXwSSXIR/i2g
X-IronPort-AV: E=Sophos;i="4.65,521,1304294400";  d="scan'208";a="2135516"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-7.cisco.com with ESMTP; 12 Jul 2011 14:04:19 +0000
Received: from Freds-Computer.local (sjc-vpn6-2000.cisco.com [10.21.127.208]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6CE4IKC007878; Tue, 12 Jul 2011 14:04:18 GMT
Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 12 Jul 2011 10:04:19 -0400
X-PGP-Universal: processed; by Freds-Computer.local on Tue, 12 Jul 2011 10:04:19 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <7FC8F60B-469E-4635-B5C0-4FD6B9AC30F8@g11.org.uk>
Date: Tue, 12 Jul 2011 10:04:09 -0400
Message-Id: <3C0C6442-E0A9-4B44-80AB-2BCDFA029D6B@cisco.com>
References: <4E0AE696.4020603@piuha.net> <7FC8F60B-469E-4635-B5C0-4FD6B9AC30F8@g11.org.uk>
To: ken carlberg <carlberg@g11.org.uk>
X-Mailer: Apple Mail (2.1084)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: homegate@ietf.org
Subject: Re: [homegate] HOMENET working group proposal
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: Tue, 12 Jul 2011 14:04:21 -0000

On Jul 12, 2011, at 9:11 AM, ken carlberg wrote:

> ...I was wondering where something like buffer-bloat, and in =
particular supporting/managing AQM, would fit in given the above.  Jim =
Getty's talk at the last IETF meeting was well received and appeared to =
open some eyes to an issue that seemed to have been easily overseen.  My =
impression is that work in Home Networks could help address some of the =
items that Jim brought up in his presentation.

I think that the need is felt in home, SOHO, and hotel (eg, broadband =
last mile) networks, and suggestions I have made along such lines have =
focused on them. However, the topic is closer to the charter of tsvwg =
IMHO, except in the ways that it manifests in broadband interfaces (the =
fact of the router, modem, CMTS/DSLAM, and upstream router being =
separate entities with separate buffers). The problem is in essence that =
ECN/AQM is generally not implemented in such networks, in part because =
there is a sense on the carrier side that loss is a bad thing, and in =
part because tuning the algorithms can be a pain. What the Georgia Tech =
folks have worked out, as much as anything, is an acceptable =
configuration driven by user perceptions rather than research =
optimizations (eg, for them it's not about finding the absolute knee of =
the curve and making the combined queue be as thin as possible, but =
finding a pragmatic solution that is predictable and acceptable to the =
typical user).=

From carlberg@g11.org.uk  Tue Jul 12 07:33:09 2011
Return-Path: <carlberg@g11.org.uk>
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 395E921F8700 for <homegate@ietfa.amsl.com>; Tue, 12 Jul 2011 07:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.158
X-Spam-Level: 
X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.441,  BAYES_00=-2.599]
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 cUAIjMNVfiWR for <homegate@ietfa.amsl.com>; Tue, 12 Jul 2011 07:33:08 -0700 (PDT)
Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4926821F86FB for <homegate@ietf.org>; Tue, 12 Jul 2011 07:33:07 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=mRHr4N1mRmCdUJiZrtZDyNU6vUNwbM9xPZeUSvBSSgduRmwnIqKMhe5eWzsSaMchB3JSl1RdDfkrhbJ6y2dbRWpUQoUW7FGRHYNSb4GXq8XxRWCZ2nEjLATe+B9QLJD9;
Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:61305 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from <carlberg@g11.org.uk>) id 1Qge1C-00014M-JP; Tue, 12 Jul 2011 14:32:58 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: ken carlberg <carlberg@g11.org.uk>
In-Reply-To: <3C0C6442-E0A9-4B44-80AB-2BCDFA029D6B@cisco.com>
Date: Tue, 12 Jul 2011 10:33:04 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D8BC195-1251-4E9E-A7A5-46EB64A1678E@g11.org.uk>
References: <4E0AE696.4020603@piuha.net> <7FC8F60B-469E-4635-B5C0-4FD6B9AC30F8@g11.org.uk> <3C0C6442-E0A9-4B44-80AB-2BCDFA029D6B@cisco.com>
To: Fred Baker <fred@cisco.com>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: homegate@ietf.org
Subject: Re: [homegate] HOMENET working group proposal
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: Tue, 12 Jul 2011 14:33:09 -0000

Fred,

> I think that the need is felt in home, SOHO, and hotel (eg, broadband =
last mile) networks, and suggestions I have made along such lines have =
focused on them. However, the topic is closer to the charter of tsvwg =
IMHO, except in the ways that it manifests in broadband interfaces (the =
fact of the router, modem, CMTS/DSLAM, and upstream router being =
separate entities with separate buffers). The problem is in essence that =
ECN/AQM is generally not implemented in such networks, in part because =
there is a sense on the carrier side that loss is a bad thing, and in =
part because tuning the algorithms can be a pain. What the Georgia Tech =
folks have worked out, as much as anything, is an acceptable =
configuration driven by user perceptions rather than research =
optimizations (eg, for them it's not about finding the absolute knee of =
the curve and making the combined queue be as thin as possible, but =
finding a pragmatic solution that is predictable and acceptable to the =
typical user).

given that a lot of these boxes are linux-based, is it a case of not =
being implemented, or simply not being turned on in the shipped image?  =
And if the latter, then perhaps Homegate/Homenet offers us a means of =
configuring ECN/AQM.

And I agree, the algorithms would be something that is advanced in =
TSVWG.  And we're also in agreement that the home/SOHO/hotel segment is =
just one part of where bufferbloat can manifest itself.

-ken


From mark@townsley.net  Wed Jul 13 05:07:45 2011
Return-Path: <mark@townsley.net>
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 18B9821F88AC for <homegate@ietfa.amsl.com>; Wed, 13 Jul 2011 05:07:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 PzWpF6-vMu0W for <homegate@ietfa.amsl.com>; Wed, 13 Jul 2011 05:07:41 -0700 (PDT)
Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id D469E21F88A6 for <homegate@ietf.org>; Wed, 13 Jul 2011 05:07:40 -0700 (PDT)
Received: by fxe4 with SMTP id 4so7363910fxe.27 for <homegate@ietf.org>; Wed, 13 Jul 2011 05:07:40 -0700 (PDT)
Received: by 10.223.145.22 with SMTP id b22mr1643138fav.95.1310558859942; Wed, 13 Jul 2011 05:07:39 -0700 (PDT)
Received: from [192.168.0.106] (dan75-4-82-239-58-63.fbx.proxad.net [82.239.58.63]) by mx.google.com with ESMTPS id w15sm10483414faj.23.2011.07.13.05.07.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Jul 2011 05:07:37 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley <mark@townsley.net>
In-Reply-To: <4D8BC195-1251-4E9E-A7A5-46EB64A1678E@g11.org.uk>
Date: Wed, 13 Jul 2011 14:07:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <DB7C38AB-F2C0-4C03-A8AC-BD1A49FCE93D@townsley.net>
References: <4E0AE696.4020603@piuha.net> <7FC8F60B-469E-4635-B5C0-4FD6B9AC30F8@g11.org.uk> <3C0C6442-E0A9-4B44-80AB-2BCDFA029D6B@cisco.com> <4D8BC195-1251-4E9E-A7A5-46EB64A1678E@g11.org.uk>
To: ken carlberg <carlberg@g11.org.uk>
X-Mailer: Apple Mail (2.1084)
Cc: homegate@ietf.org
Subject: Re: [homegate] HOMENET working group proposal
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: Wed, 13 Jul 2011 12:07:45 -0000

On Jul 12, 2011, at 4:33 PM, ken carlberg wrote:

> Fred,
>=20
>> I think that the need is felt in home, SOHO, and hotel (eg, broadband =
last mile) networks, and suggestions I have made along such lines have =
focused on them. However, the topic is closer to the charter of tsvwg =
IMHO, except in the ways that it manifests in broadband interfaces (the =
fact of the router, modem, CMTS/DSLAM, and upstream router being =
separate entities with separate buffers). The problem is in essence that =
ECN/AQM is generally not implemented in such networks, in part because =
there is a sense on the carrier side that loss is a bad thing, and in =
part because tuning the algorithms can be a pain. What the Georgia Tech =
folks have worked out, as much as anything, is an acceptable =
configuration driven by user perceptions rather than research =
optimizations (eg, for them it's not about finding the absolute knee of =
the curve and making the combined queue be as thin as possible, but =
finding a pragmatic solution that is predictable and acceptable to the =
typical user).
>=20
> given that a lot of these boxes are linux-based, is it a case of not =
being implemented, or simply not being turned on in the shipped image?  =
And if the latter, then perhaps Homegate/Homenet offers us a means of =
configuring ECN/AQM.

Certainly, a primary homenet requirement would be that the parameters =
configure themselves so that a user does not have to.=20

- Mark

>=20
> And I agree, the algorithms would be something that is advanced in =
TSVWG.  And we're also in agreement that the home/SOHO/hotel segment is =
just one part of where bufferbloat can manifest itself.
>=20
> -ken
>=20
> _______________________________________________
> homegate mailing list
> homegate@ietf.org
> https://www.ietf.org/mailman/listinfo/homegate


From rturner@amalfisystems.com  Wed Jul 13 05:58:06 2011
Return-Path: <rturner@amalfisystems.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 1783221F853A for <homegate@ietfa.amsl.com>; Wed, 13 Jul 2011 05:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 2JCWt5kOq971 for <homegate@ietfa.amsl.com>; Wed, 13 Jul 2011 05:58:05 -0700 (PDT)
Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by ietfa.amsl.com (Postfix) with ESMTP id 848C321F856F for <homegate@ietf.org>; Wed, 13 Jul 2011 05:58:05 -0700 (PDT)
Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id p6DCw4lV010052 for <homegate@ietf.org>; Wed, 13 Jul 2011 08:58:04 -0400
X-Authenticated-IP: 174.254.69.245
Received: from [174.254.69.245] ([174.254.69.245:58283] helo=[10.247.147.234]) by cm-omr2 (envelope-from <rturner@amalfisystems.com>) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id 56/DC-04012-C569D1E4; Wed, 13 Jul 2011 08:58:04 -0400
References: <4E0AE696.4020603@piuha.net> <7FC8F60B-469E-4635-B5C0-4FD6B9AC30F8@g11.org.uk> <3C0C6442-E0A9-4B44-80AB-2BCDFA029D6B@cisco.com> <4D8BC195-1251-4E9E-A7A5-46EB64A1678E@g11.org.uk> <DB7C38AB-F2C0-4C03-A8AC-BD1A49FCE93D@townsley.net>
In-Reply-To: <DB7C38AB-F2C0-4C03-A8AC-BD1A49FCE93D@townsley.net>
Mime-Version: 1.0 (iPhone Mail 8E401)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <8191C026-8791-4320-ABDA-A9EFB9B8458E@amalfisystems.com>
X-Mailer: iPhone Mail (8E401)
From: Randy Turner <rturner@amalfisystems.com>
Date: Wed, 13 Jul 2011 05:58:02 -0700
To: Mark Townsley <mark@townsley.net>
Cc: "homegate@ietf.org" <homegate@ietf.org>
Subject: Re: [homegate] HOMENET working group proposal
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: Wed, 13 Jul 2011 12:58:06 -0000

+1 on the self-configuring of parameters

Randy

On Jul 13, 2011, at 5:07 AM, Mark Townsley <mark@townsley.net> wrote:

>=20
> On Jul 12, 2011, at 4:33 PM, ken carlberg wrote:
>=20
>> Fred,
>>=20
>>> I think that the need is felt in home, SOHO, and hotel (eg, broadband la=
st mile) networks, and suggestions I have made along such lines have focused=
 on them. However, the topic is closer to the charter of tsvwg IMHO, except i=
n the ways that it manifests in broadband interfaces (the fact of the router=
, modem, CMTS/DSLAM, and upstream router being separate entities with separa=
te buffers). The problem is in essence that ECN/AQM is generally not impleme=
nted in such networks, in part because there is a sense on the carrier side t=
hat loss is a bad thing, and in part because tuning the algorithms can be a p=
ain. What the Georgia Tech folks have worked out, as much as anything, is an=
 acceptable configuration driven by user perceptions rather than research op=
timizations (eg, for them it's not about finding the absolute knee of the cu=
rve and making the combined queue be as thin as possible, but finding a prag=
matic solution that is predictable and acceptable to the typical user).
>>=20
>> given that a lot of these boxes are linux-based, is it a case of not bein=
g implemented, or simply not being turned on in the shipped image?  And if t=
he latter, then perhaps Homegate/Homenet offers us a means of configuring EC=
N/AQM.
>=20
> Certainly, a primary homenet requirement would be that the parameters conf=
igure themselves so that a user does not have to.=20
>=20
> - Mark
>=20
>>=20
>> And I agree, the algorithms would be something that is advanced in TSVWG.=
  And we're also in agreement that the home/SOHO/hotel segment is just one p=
art of where bufferbloat can manifest itself.
>>=20
>> -ken
>>=20
>> _______________________________________________
>> homegate mailing list
>> homegate@ietf.org
>> https://www.ietf.org/mailman/listinfo/homegate
>=20
> _______________________________________________
> homegate mailing list
> homegate@ietf.org
> https://www.ietf.org/mailman/listinfo/homegate
>=20

From rdroms.ietf@gmail.com  Thu Jul 14 09:36:16 2011
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 E834621F8C85; Thu, 14 Jul 2011 09:36:16 -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 nyzHxrU13V95; Thu, 14 Jul 2011 09:36:16 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C8D3321F8C6F; Thu, 14 Jul 2011 09:36:15 -0700 (PDT)
Received: by iwn39 with SMTP id 39so410514iwn.31 for <multiple recipients>; Thu, 14 Jul 2011 09:36:15 -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=3zRDVgvrw7Fv/AAYM54dUogJKc29bx3vKsGUQo2M+h4=; b=lxhaLhrjrbgBdhic9dDtK+gW2Bkl3/b5z5lQZjGD9kaF01iffJ++5vZLmScO1YyTcK o4g0GABeTRAPpcWp4LpWe73kvixStvJIrSsCA9GUcIOJnPjuHoxU6uyuOQwxRNmASjKJ nkwmtvkyBqfJK/kzYOQnzzJIeQYmGCwlvmSVQ=
Received: by 10.42.71.78 with SMTP id i14mr2502365icj.364.1310661374840; Thu, 14 Jul 2011 09:36:14 -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 d8sm443842icy.21.2011.07.14.09.36.12 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jul 2011 09:36:13 -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:36:09 -0400
Message-Id: <DDA7B98D-4614-421A-BB1F-EF8238638FED@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:36:17 -0000

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,=20
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=

From mark@townsley.net  Thu Jul 14 09:41:22 2011
Return-Path: <mark@townsley.net>
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 BCE9021F8D16; Thu, 14 Jul 2011 09:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.116
X-Spam-Level: 
X-Spam-Status: No, score=-3.116 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
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 6Tryzqe6Q4om; Thu, 14 Jul 2011 09:41:21 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2EC121F8C3D; Thu, 14 Jul 2011 09:41:17 -0700 (PDT)
Received: by wyj26 with SMTP id 26so323441wyj.31 for <multiple recipients>; Thu, 14 Jul 2011 09:41:16 -0700 (PDT)
Received: by 10.216.238.80 with SMTP id z58mr6200151weq.106.1310661675066; Thu, 14 Jul 2011 09:41:15 -0700 (PDT)
Received: from ams-townsley-8714.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id fo2sm333008wbb.65.2011.07.14.09.41.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jul 2011 09:41:12 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mark Townsley <mark@townsley.net>
In-Reply-To: <DDA7B98D-4614-421A-BB1F-EF8238638FED@gmail.com>
Date: Thu, 14 Jul 2011 18:41:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A324616-8D14-42A8-B2E0-111BE0DA1ADB@townsley.net>
References: <DDA7B98D-4614-421A-BB1F-EF8238638FED@gmail.com>
To: Ralph Droms <rdroms.ietf@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: homenet@ietf.org, homegate@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [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:41:22 -0000

s/homegate/homenet

Ralph is in an airport between flights, and clearly something with the =
altitude, fumes, or drinks served caused him to slip back in time here.

- Mark

PS. The order is already in to disable the homegate list. It's =
homenet@ietf.org for everything from here on.

On Jul 14, 2011, at 6:36 PM, Ralph Droms wrote:

> 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.
>=20
> Mark will start a thread here soon to develop the agenda for the =
upcoming WG meeting.
>=20
> 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.
>=20
> - Ralph Droms
>  Internet Area Director
>=20
> Home Networks (homenet)
> -----------------------------------
>=20
> Current Status: Proposed
> Last Edit: Wednesday, July 14th, 2011
>=20
> Chairs:
> "W. Mark Townsley" <townsley@cisco.com>
>=20
> Internet Area Directors:
> Ralph Droms <rdroms.ietf@gmail.com>
> Jari Arkko <jari.arkko@piuha.net>
>=20
> Internet Area Advisor:
> Ralph Droms <rdroms.ietf@gmail.com>
>=20
> Routing Area Technical Advisor:
> TBD
>=20
> Security Area Technical Advisor:
> TBD
>=20
> 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
>=20
> Description of Working Group:
>=20
> 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:
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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:
>=20
> o  prefix configuration for routers
> o  managing routing
> o  name resolution
> o  service discovery
> o  network security
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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,=20
> as is understanding existing technology from these groups.
>=20
> Milestones:
>=20
> 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 mailing list
> homegate@ietf.org
> https://www.ietf.org/mailman/listinfo/homegate


From rdroms.ietf@gmail.com  Thu Jul 14 09:43:54 2011
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

=3D=3D=3D=3D=3D


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,=20
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=